-
Notifications
You must be signed in to change notification settings - Fork 12k
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
Feature Request : Add Support for Strict Content Security Policy #21711
Comments
I think this repo from Google can provide some directions https://github.com/google/strict-csp/tree/main/strict-csp-html-webpack-plugin |
Hi @naveedahmed1, I don't think it should be necessary do anything very fancy for CSP. We only generate scripts and styles for the same domain, so The one exception is styles, where we require We can't really generate a CSP for users as there are various attributes that apply beyond what Angular provides. Users can control their I can see the argument that SSR could generate a CSP policy to some extent. That still runs into challenges with user-controlled fields that can't be generated and has an implicit risk that attacker code in the request could poison files before hashes/nonces are generated and invalidate much of the security CSP provides. Regardless, that would be handled by Universal rather than the CLI. We can follow up there if you have a specific thought or request for SSR. We could probably do a better job documenting this, as our current CSP section is pretty limited. |
However, we're running into a scenario where it would be beneficial to use strict-dynamic, which disables It sounds like the direction that @naveedahmed1 was trying to go down might solve this issue for us. If there was a way to use hashing or nonces for the Angular bundle files, then that would probably allow us to use |
Could you expand on the scenario where it would be beneficial to use With the current internal bundler usage of Webpack, dynamic import expressions are not used for lazy loading of JavaScript but rather Webpack uses its own runtime that injects script elements into the DOM. Irrespective of the above, hashes for each script within the application can potentially be calculated as part of the deployment step for the application. This is a useful time to calculate them as the CSP configuration would need to be updated for each deployment to include those hashes. The server configuration containing the new CSP configuration can then be uploaded during deployment or forwarded to the project's infrastructure team for inclusion, if applicable. Nonces are recommended to change per request and would best be handled by Angular Universal and SSR (as mentioned in a previous comment) as Universal generates the HTML for each request and can then inject nonces as needed. |
Our use-case for
What we really want is the "trust propagation" aspect of The unfortunate (for us) side effect of browsers' current implementation is that, by design, they ignore If my current understanding is correct, then SRI is a great tool to solve a different problem, thus it wouldn't help us to achieve the "trust propagation" that we're looking for. It seems that SRI adds the hash to the script tag that's inserted into the index, whereas what we need is to add the hash to Your suggestion of calculating the hashes of the generated scripts and writing them to the CSP sounds like it would probably work. However, there are two extra things to keep in mind there:
Per my understanding I think the above are absolutely possible, but it seems to be enough engineering effort to tip the cost/benefit ratio in favor of living with long whitelists at least for the short-term. Please feel free to poke holes in the above if relevant. I might have gotten something wrong because I'm still learning the nitty-gritty details about modern CSP stuff. And thank you for your help! |
I think the original issue was about CSP in general, and Regarding @pbrowning-tt's concern, it's unfortunate that While Angular could generate a CSP with explicit hashes, we don't fully own the user's CSP string, as dynamic behavior in the app can require other changes to the CSP which we couldn't possibly generate (such as Our current approach has been to let users deal with the CSP strings and require minimal exceptions for Angular to allow the policy to be as strict as possible. Future CSP features might allow Angular to be more intelligent than We should definitely update our docs about this to be more clear about |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
🚀 Feature request
Command (mark with an
x
)Description
Lighthouse now throws error if No CSP is found in enforcement mode.
Ensure CSP is effective against XSS attacks
No CSP found in enforcement mode
withHigh Severity
Describe the solution you'd like
My knowledge about CSP is limited and I was going through these guides on CSP:
http://web.dev
https://web.dev/csp-xss/
https://web.dev/strict-csp/
Apparently Nonce-based CSP seems easy to implement for SSR, for example for scripts, after Angular returns the final html, we can use string replace function on server side, to replace "<script" with "<script nonce="RANDOM_NONCE"" add RANDOM_NONCE in CSP header and I believe it should work.
But this string replace work will have to be done for each request.
On the other hand, in case of Hash-based strict CSP if Angular CLI calculates hashes and include these hashes in script tags at build time, this could save us the string replace work that has to be done for each request in case of nonce. But there's a tradeoff, we will have to sync these hashes with our Server Side App so that appropriate headers could be added for generated response. Alternatively CSP could be generated by Angular CLI and added as
Content-Security-Policy
meta tag.Ref: https://web.dev/strict-csp/#step-1:-decide-if-you-need-a-nonce-or-hash-based-csp
Criteria for choosing a strict CSP approach:
The text was updated successfully, but these errors were encountered: