Chrome throws a SecurityError while Firefox does not

[teddink]

The Edge team is currently implementing CSP2 and we are onboarding the w3c/web-platform-tests for CSP. We found a couple of instances where Chrome and Firefox disagree.

Both browsers correctly block the action and send a CSP report. However, sometimes additionally Chrome throws a SecurityError, while Firefox does not.

We haven’t been through all the tests yet, but the pattern seems to be that Chrome throws for actions that can only be instigated via <script>:
• When creating a new EventSource to a blocked URL, Chrome throws while FireFox quietly closes the connection.
• When using ‘sendBeacon’ to send to a blocked URL, Chrome throws while FireFox quietly sends nothing.

The connect-src section of the spec seems to leave the correct behavior ambiguous. What is the expected behavior here?

[michaelficarra]

1. connect-src Pre-request check returns "Blocked"
2. Should request be blocked by Content Security Policy? returns "Blocked"
3. Main fetch step 5 sets response to a network error.
4. The user agent then does whatever it's supposed to do with a network error from fetch in that particular context.

[annevk]

@teddink you should get an error event on EventSource in Firefox. I forgot how sendBeacon() surfaces network errors, I suppose it doesn't.

[mikewest]

@teddink you should get an error event on EventSource in Firefox.

Indeed. We originally were throwing in XHR, EventSource, etc. @annevk convinced me to change it a million years ago, as it aligns the behavior between redirect blockage and non-redirect blockage, and simplifies the interface to Fetch. I thought we updated Chrome, but it's entirely possible that we didn't.

In other words, this sounds like a Chrome bug and not a spec bug. If you file a bug against Chrome, I'll get it fixed.

I forgot how sendBeacon() surfaces network errors, I suppose it doesn't.

sendBeacon() is fire-and-forget. It doesn't surface errors, as its lifetime is decoupled from the context of the document.

[teddink]

Here you go Mike: 651879

[mikewest]

This was fixed in Igalia/chromium@8a4e051.