Why Do You See “Script Error” in Chrome? Causes, Fixes, and Best Practices

Script Error: Causes and Current Solutions

When a browser’s same‑origin policy blocks an unknown cross‑origin script, it throws the generic "Script error." message, preventing developers from seeing the actual error location. The usual fix is to add the

crossorigin

attribute to the

<script>

tag and configure the server to send the

Access-Control-Allow-Origin

header.

Some hacky approaches proxy the native API and wrap business code in

try…catch

, but poorly written proxies introduce hidden bugs and performance overhead, making this strategy unattractive.

Common Issues

crossorigin is hard to add – asynchronous script loading can create a chain (A loads B, B loads C) making it unclear which external scripts are involved.

crossorigin cannot be added – external code injected by browser extensions or custom WebView containers.

Invalid Script Error data makes it difficult to assess business impact and wastes monitoring resources.

Root Cause: Why “Script Error” Exists

In 2006 a security paper showed that error messages could reveal a user’s login state. By loading a script from the target site, an attacker could see different error outputs for logged‑in versus logged‑out users, enabling targeted attacks.

<code>&lt;script src="http://mail.google.com/mail/"&gt;&lt;/script&gt;</code>

Examples of logged‑in and logged‑out error screenshots are shown below.

WHATWG standardized the error‑information exposure to avoid leaking script URLs, and Chrome follows this spec.

Can the Script Error Specification Be Adjusted?

Given modern browsers’ robust same‑origin policies, the WHATWG discussion concluded that exposing script URLs or other details is not desirable; the spec intentionally hides them.

Discussion links: https://github.com/whatwg/html/issues/2440, https://github.com/whatwg/html/issues/5051

How Major Companies Handle Script Error

Tests on several large sites show different strategies:

Google: reports Script Error directly.

Twitter (and GitHub, Facebook): blocks unknown scripts via CSP.

QQ Video: reports Script Error and monitors asynchronously loaded scripts.

<code>var s = document.createElement('script');
s.src = 'https://g.alicdn.com/dinamic/h5-tb-cart/5.0.41/index.min.js';
document.body.appendChild(s);
</code>

Future‑Oriented Recommendations

We should not fight the spec; same‑origin policies will only improve. Relying solely on

Access-Control-Allow-Origin

is insufficient. A reasonable short‑term solution is to enhance cross‑origin script visibility via CSP Report‑Only and fix missing

crossorigin

on critical scripts.

CSP Report‑Only documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only

<code>document.querySelectorAll('script[src]:not([crossorigin])')</code>

Reference Documents

What is script error – https://blog.sentry.io/2016/05/17/what-is-script-error

Cryptic “Script Error.” reported in Chrome and Firefox – https://stackoverflow.com/questions/5913978/cryptic-script-error-reported-in-javascript-in-chrome-and-firefox

Alternative approaches to solving “Script Error” – https://juejin.cn/post/6844903727820718094#heading-6

iOS privacy tracking – https://krausefx.com/blog/ios-privacy-instagram-and-facebook-can-track-anything-you-do-on-any-website-in-their-in-app-browser

I know if you’re logged‑in, anywhere – https://blog.jeremiahgrossman.com/2006/12/i-know-if-youre-logged-in-anywhere.html

HTML Spec: Runtime script errors – https://html.spec.whatwg.org/multipage/webappapis.html#runtime-script-errors

“Script error.” message in window.onerror makes bad DevExp trade off – https://github.com/whatwg/html/issues/2440

unhandledrejection should fire even for muted scripts – https://github.com/whatwg/html/issues/5051

Content‑Security‑Policy‑Report‑Only – https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only