New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user

Issue metadata

Status: Fixed
OOO (parental leave)
Closed: May 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Content-Security-Policy-Report-Only header isn't enforced when issued alongside the Content-Security-Policy header

Reported by, Jun 23 2015

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36

Steps to reproduce the problem:
1. Create and issue a valid CSP and CSPRO header.
2. Load a page with an asset that violates the CSP and CSPRO header.
3. The console only indicates the violation for the CSP and not the CSPRO header.
4. The violation report is only sent for the CSP header and not the CSPRO header.

What is the expected behavior?
The browser should act upon both the CSP and CSPRO header if they are present. The browser should also deliver violation reports for the CSP and CSPRO header if both policies have a report-uri directive specified.

What went wrong?
I issued the following 2 policies on

content-security-policy: default-src https: data: 'unsafe-inline' 'unsafe-eval'; report-uri

content-security-policy-report-only: default-src https: data: 'unsafe-inline' 'unsafe-eval'; report-uri

When visiting, which contains a CSP violation by loading an offending image asset, the console only reports a violation of the CSP header and not the CSPRO header. Further to this, a violation is only sent to the URI specified in the CSP header and not the CSPRO header. 

Tested on Firefox 38.0.5 which works as expected. Violations are displayed and sent for both the CSP and CSPRO header.

Did this work before? N/A 

Chrome version: 43.0.2357.124  Channel: n/a
OS Version: 8.1 Pro x64
Flash Version:
92.9 KB View Download
68.5 KB View Download

Comment 1 by, Jun 24 2015

Status: Assigned
This does sound like a bug, as per, all policies should be enforced/applied. Strictly speaking, this isn't a bug, but until we confirm that this is only occurring with report-only headers, I'm leaving this marked as a security bug.
There are further details associated with handling report only headers here:

Comment 3 by, Jun 25 2015

Certainly sounds like a bug. Both headers should be processed and enforced/monitored.

Comment 4 by, Jun 25 2015

Labels: -Restrict-View-SecurityTeam -Type-Bug-Security Cr-Blink-SecurityFeature Type-Bug
Ha. Ok. This has never worked correctly. As soon as any policy blocks the request, we skip the rest: If we'd processed report-only headers first, both would be reported (but we'd still break reporting if there are multiple enforce-mode headers). Hooray for ~4-year old bugs. :/

I don't believe this is a security issue, but it's annoying regardless. Dropping the restrict-view flag, and categorizing correctly.
This issue now appears to be resolved and reports are being sent for the CSPRO header in Version 43.0.2357.134 m. Has there been some change not indicated on this bug?
Update to this bug. Behaviour has changed. 

On this page:
I issue the following policies:

Content-Security-Policy: img-src 'self' data: *snip domains for sanity*; report-uri

Content-Security-Policy-Report-Only: img-src 'self' data: *snip domains for sanity*; report-uri

The page intentionally loads the following offending asset using the ftp scheme which is not permitted:
<img src="">

I get a CSP report from the enforced policy but *not* from the report-only policy. The policies do differ and Firefox does send a report for each policy for the particular asset. 
After further thought I'm going to raise a new issue as this doesn't exactly match the original issue title. 
 Issue 601212  has been merged into this issue.
Labels: -OS-Windows OS-All
Mike, I assume you won't be too upset if I take this from you.

I think this is a simple fix as alluded to in comment 4: we just need to loop through all the policies instead of exiting early... I might be missing some subtlety though.
If that's the case, and the report-only header was defined first, does that mean if the report-only policy "blocked" it you'd potentially not check the enforced policy and actually block it?
Re #10: hmmm.... no, I don't think so. We only exit early if the load was actually blocked.

This is the method whose return value we check to decide whether to exit early:

It returns true if it's a report-only policy, and only returns false if the load violated the policy and the policy is actually being enforced.
Here's a patch, needs moar tests though:
Project Member

Comment 13 by, May 9 2016

The following revision refers to this bug:

commit c9aac646c5b7be2c1dc2c0db0ac79fcedbaceee9
Author: estark <>
Date: Mon May 09 19:38:11 2016

Check all CSPs rather than exiting early if a resource is blocked

Previously, if a single policy blocked a resource load, we would exit
early and not check the load against any other policies that might be in
effect. Checking other policies, however, might have side effects (like
sending reports) that should execute even if the load has already been

BUG= 503730 

Cr-Commit-Position: refs/heads/master@{#392398}


Labels: M-52
Status: Fixed (was: Assigned)

Sign in to add a comment