-
-
Notifications
You must be signed in to change notification settings - Fork 154
Extend CSP Configuration #911
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
Conversation
|
Ah I was unaware of the playwright tests - looks like they caught a bug in my implementation. Cool, I will sort it out. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for taking the time to dive in !
This is a good start, but the logic is a little bit wrong here. Each nonce has to be used only once. We cannot define a random nonce on startup and then use it repeatedly. Otherwise an attacker can easily make a script injection that contains the known nonce.
How I think it should work:
- in app_config, we store a parsed csp string. It could be something as simple as
struct CSPFormat { before_nonce: String, after_nonce: String } - add a method to request_context.content_security_policy that takes a
CSPFormatand generates a header. - in render.rs, replace the csp insertion with
request_context.content_security_policy.add_to_response(&mut response, app_state.config.content_security_policy)
|
Yep makes sense +1. I'll take another run at this tomorrow and ensure each nonce is per-request. |
…ght test to verify subsequent requests return a different nonce.
|
OK this should now be correct (I added an e2e test to verify). Let me know what you think! |
we are still re-parsing the csp template on every request
af329fc to
a88f350
Compare
|
Done. Thank you @guspower ! |
|
Excellent thank you @lovasoa !!! |
A first pass implementation as discussed in issue #909
Let me know what you think - I'll update the docs when you're happy with it.