-
Notifications
You must be signed in to change notification settings - Fork 78
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
'unsafe-inline', 'unsafe-eval', nonce-source, hash-source are no-op for most of the source-list directives #22
Comments
I'm not sure if that complexity is worthwhile. That is, What's the down side to accepting these in the grammar, but ignoring them? |
Maybe, to make things clear for the implementers, explicitly mention in the spec that nonce-source, hash-source, |
Another reason to separate executable contents' grammar is to minimize policy length:
can be optimized into |
|
But then you can't call it spec compliant optimizer. Hard choice. Feel free to close the issue. |
While
'unsafe-inline'
,'unsafe-eval'
,nonce-source
,hash-source
are validsource-expression
values, only default-src, script-src and style-src define parsing for above keywords.It would make sense to define something like
executable-source-expression
with appropriate grammar and use it for default-src, script-src and style-src, while make other source-list directives usesource-expression
.The text was updated successfully, but these errors were encountered: