Open Bug 1200566 Opened 9 years ago Updated 2 years ago

Content Security Policy in Web Worker

Categories

(Core :: Security, defect)

40 Branch
All
Windows 7
defect

Tracking

()

UNCONFIRMED

People

(Reporter: nadoedalo, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36

Steps to reproduce:

Set header : Content-Security-Policy : default-src 'self';
run any unsafe-code in Web Worker like
new window.Worker('/pathToScriptWithEval.js');
Set header for pathToScriptWithEval.js Content-Security-Policy : default-src 'none'; sript-src 'unsafe-eval';


Actual results:

CSP error about unsafe-eval from original window


Expected results:

CSP applied to worker itself by it's own header if it has one because worker is totally independent in sandbox and not the same as original window.

Chrome works fine with separate policies for original window and worker sandbox and it seems like very good protection agains xss and evil scripts.
OS: Unspecified → Windows 7
Hardware: Unspecified → All
Indeed. The CSP standard states the following which supports your report IMHO:

"If the worker’s script is delivered with a Content-Security-Policy HTTP header containing the value policy, the user agent MUST enforce policy for the worker."

With NSPR_LOG_MODULES="CSPParser:4" set, I even only see the parsing of the my test page's CSP, not of the script's CSP. I can't quite figure out however where the CSP parsing should be done.
Summary: Content Secutity Policy in Web Worker → Content Security Policy in Web Worker
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.