1794712 - CSP fetch errors are not catchable in a Service Worker

Status: RESOLVED WORKSFORME

(Core :: DOM: Security, defect)

Description

[randylebeau]

Steps to reproduce:

1. Set up an HTML page with the CSP rule default-src: self and add an off origin stylesheet.

2. In the fetch handler, perform a sub request to fetch the asset wrapped in a try catch.

Actual results:

The sub request returns with a 200 status code and when the response makes it to the browser, the CSP error is thrown.

Expected results:

The fetch sub request in the service worker should have thrown an error so a fallback could be implemented or a custom response sent to the client. As far as I know, this is the behavior on other browsers.

Also, credentials should default to include for CORS requests, currently they default to self.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

CSP is more DOM: Security stuff.

Comment 3

[randylebeau]

👍 The CSP component itself is fine, the issue is where the error is raised. IMO the fetch request in the service worker should throw the CSP error so it can be caught and handled.

Comment 4

[Daniel Veditz [:dveditz]]

I'm having trouble imagining your scenario. If the CSP restricts resources to 'self' how was the request not blocked before it got sent to the "off origin" service worker? was there a redirect on the request? Do you have a simple testcase (or public site) that shows the bug?

Comment 5

[Daniel Veditz [:dveditz]]

Sorry, "off origin stylesheet" or is it a service worker? I'm confused by the scenario. "Fetch handler" makes me think of service workers, but that's not what you said.

Comment 6

[randylebeau]

Ah, yeah I should have included the service worker in the description, but its in the title. The problem actually extends beyond CSP as a CORS error results in the same bug.

The behavior that I would expect is that the fetch call inside the service worker would throw CSP and CORS errors so I can implement some fallback logic inside the service worker request.

In actuality, the fetch inside the service worker succeeds with a 200 response and only when its returned back to the browser is the response rejected by CORS or CSP rules.

Does that make sense? If not I can try to set up a test case on Friday.

Comment 7

[randylebeau]

Sorry by "browser" I mean the main thread. It seems like the Service Worker proxy is not checking for browser enforced security rules as it does in other browsers. It seems to behave more like a server proxy.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:freddy, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 9

[Frederik Braun [:freddy]]

A test case would be very helpful. It's not yet clear to me if the issue is with CSP's handling of the request or with our ServiceWorker code.

Comment 10

[randylebeau]

So I made a simple test case in an attempt to reproduce, but it seems like the bug is no longer present on the latest nightly build. Im going to re-enable Firefox on our production service worker next week and see if the problem persists. My testing with a web proxy shows that it should be working now. Not sure if it's because the origin fixed the CSP violation or something else, but I will need to gather some more field data.

You can feel free to close this issue if you like. I can create a new one if I'm able to create a reliable reproduction.

Thanks for your time.