New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow report-uri in meta tags. #278
Comments
After doing some quick research it seems the concern here was an attacker injecting a meta tag such as:
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. |
The difference is though that injected JS won't run unless I don't think we can safely allow |
I agree with @andypaicu. Injecting It's fine to revisit the conversation around |
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. |
GitHub pages. Amazon S3. Lots of other static hosts.
I don't disagree! |
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 |
👍 Closing this out in favor of #277. |
You agree with Mike that |
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. |
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.
The text was updated successfully, but these errors were encountered: