Skip to content
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

Closed
shekyan opened this issue Oct 12, 2015 · 5 comments

Comments

@shekyan
Copy link
Contributor

shekyan commented Oct 12, 2015

While 'unsafe-inline', 'unsafe-eval', nonce-source, hash-source are valid source-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 use source-expression.

@mikewest
Copy link
Member

I'm not sure if that complexity is worthwhile. That is, 'unsafe-eval' certainly doesn't do anything for connect-src, but that's fine, because user agents ignore it during the matching algorithm, and they don't have to special-case the parser for any of the fetch directives.

What's the down side to accepting these in the grammar, but ignoring them?

@shekyan
Copy link
Contributor Author

shekyan commented Oct 17, 2015

Maybe, to make things clear for the implementers, explicitly mention in the spec that nonce-source, hash-source, 'unsafe-eval' and 'unsafe-inline' are ignored while parsing for the rest of the directives. I agree that introducing new grammar will make things complicated.

@shekyan
Copy link
Contributor Author

shekyan commented Oct 19, 2015

Another reason to separate executable contents' grammar is to minimize policy length:

Content-Security-Policy: script-src 'nonce-123'; style-src 'nonce-123'

can be optimized into default-src 'nonce-123'.
But if one implements spec compliant parser, the optimization would happen only if every single directive type that consumes source-list is explicitly specified.

@mikewest
Copy link
Member

  1. Optimizers should be free to use their understanding of implementation quirks to do The Right Thing(tm) for the code. :)
  2. It's not clear that that's a safe transformation forever and ever. That is, requests like Nonce attribute for Web Worker #15 would break the assumption you're making about nonces' applicability. More generally, there's no reason that a nonce couldn't be applied to things like images or forms or XHR or whatever. shrug

@shekyan
Copy link
Contributor Author

shekyan commented Oct 19, 2015

But then you can't call it spec compliant optimizer. Hard choice. Feel free to close the issue.

@shekyan shekyan closed this as completed Oct 20, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants