search

w3c / webappsec-csp

WebAppSec Content Security Policy
https://w3c.github.io/webappsec-csp/
Other
209 stars 78 forks source link

Consider providing a way to tighten source-expressions that contain `self` #91

Open shekyan opened 8 years ago

shekyan commented 8 years ago

Currently, it is not possible to tighten source-expressions to a specific path-part, other then resolve self on your own.

I think there is a value to allow source-expression like 'self'/user/ that can be useful for user content isolation, etc.

shekyan commented 8 years ago

Was also mentioned in https://www.w3.org/2011/webappsec/track/issues/73?changelog

mikewest commented 8 years ago

@marumari asked about this earlier today. I told her that "An issue is back-compat. That is, I don't know how we'd construct a policy that worked in Safari and the new Firefox that supported that new mechanism. I mean, we could do something like 'self' 'self/path', wherethe presence of the latter would invalidate the former (as we do with 'unsafe-inline' 'nonce-*'), but, you know."

mikewest commented 8 years ago

(For clarity, I don't think this is something we can easily do. But I'll mark it as blocking CR just so we make a decision about that one way or the other.)

april commented 7 years ago

Another reason to consider this: http://blog.portswigger.net/2016/12/bypassing-csp-using-polyglot-jpegs.html

april commented 7 years ago

One way to do it is to use an arbitrary scheme:

self:///path/to/js or self://../js or something. It would still have to invalidate 'self', but at least it's a bit more self-documenting than 'unsafe-inline' + nonce-*.

andypaicu commented 6 years ago

I agree it would be useful worth considering for future CSP