WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
151548
Errors in CORS scripts are oversanitized
https://bugs.webkit.org/show_bug.cgi?id=151548
Summary
Errors in CORS scripts are oversanitized
Eddie Kohler
Reported
2015-11-22 10:39:13 PST
A page on domain A includes a script on domain B with `crossorigin="anonymous"`. B serves the script with `Access-Control-Allow-Origin: *`. The script sets a `window.onerror` handler. The expected behavior is that errors are not sanitized, and the `onerror` handler gets full error information. This is what happens in Chrome (46.0.2490.80) and Firefox (36.0.1, 42). I think older Safari versions also acted this way. Safari (9.0.1 (11601.2.7.2) and nightly (
r192726
)) implements strictly less useful behavior. If the error occurs in the domain-A page, full error information is provided. But if the error occurs *in the domain-B script*, the error is sanitized. Page showing the problem:
http://www.lcdf.org/~eddietwo/test-cors-script.html
Firefox output: TypeError: cause_error.error is not a function ReferenceError: x is not defined Chrome output: Uncaught TypeError: cause_error.error is not a function Uncaught ReferenceError: x is not defined Safari/WebKit output: Script error. ReferenceError: Can't find variable: x
Attachments
Safari 15.5 error differs from other browsers
(1.42 MB, image/png)
2022-05-30 09:30 PDT
,
Ahmad Saleem
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Arthur Buldauskas
Comment 1
2016-11-30 07:43:01 PST
Still happens on Safari 9.1.1 on a El Capitan 10.11.5 Verified that this also affects iOS Safari 9.3 to 8.4 at least. This is a major issue. Ran into this trying to fix error reporting for JS errors coming from our scripts fetched from CDN(s). This makes Safari a black hole of bugs, where no error information escapes. Cannot believe that no one bothered to look into this for over a year.
youenn fablet
Comment 2
2016-12-01 08:12:55 PST
The issue does not seem to be related with CORS checks per se but more on how we keep/retriev that information around. The main script element is inline so there is no CachedScript and The cachedScript passed to ScriptExecutionContext::sanitizeScriptError is the top-level script which is inline, so it is null. We rely solely on the source URL, which is the one of the cross-origin subresource, hence the issue. I am not sure of the best way to retrieve the related CachedScript here. Or even if that should be done that way. Any insight?
Ahmad Saleem
Comment 3
2022-05-30 09:30:02 PDT
Created
attachment 459864
[details]
Safari 15.5 error differs from other browsers I was able to reproduce this bug using Safari 15.5 and all other browsers in the screenshots shows consistent error. Thanks!
Divya
Comment 4
2024-05-14 14:09:47 PDT
is there any update on this? Facing the same issue
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug