- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Fri, 2 Dec 2016 11:23:09 -0500
- To: whatwg@lists.whatwg.org
On 12/2/16 11:01 AM, Michael A. Peters wrote:
> Personally I love CSP but it does not allow inline scripts or inline CSS
Only if you say to not allow them. The default behavior allows them.
For example, this disallows inline scripts, because script-src is
explicitly specified without unsafe-inline, but does nothing about
inline CSS:
<!DOCTYPE html>
<meta http-equiv="content-security-policy"
content="script-src 'self'">
<style>body { color: green; }</style>
This is green
<script>alert("I am not alerted")</script>
> I believe there now are CSP parameters that relax those prohibitions but
> from I understand they are only relaxed when a hash of the inline
> scripts / CSS is declared in the head.
That's ... not correct. Simple example; compare it to the previous one:
<!DOCTYPE html>
<meta http-equiv="content-security-policy"
content="script-src 'self' 'unsafe-inline'">
<style>body { color: green; }</style>
This is green
<script>alert("I am alerted")</script>
> and that too isn't
> compatible with CSP where the scripts need to be defined in the head
Uh... No, they do not. Neither of my examples above has a <script> in
the <head>
> (except for maybe with the new unsafe-inline option that requires
> checksum in the head ???)
unsafe-inline doesn't require a checksum. See examples above.
> I just know that most websites break as soon as a CSP header is sent
That really depends on the header sent. If you send a header whose
value is the empty string, for example, it will have no effect
whatsoever. If you send a header which only has a object-src directive,
and you don't use <object>, it will have no effect whatsoever.
If you send something with very restrictive script-src and style-src,
then well, you have to work within those restrictions.
> and it isn't always trivial to make them work.
If you want to impose sufficiently stringent restrictions, sure.
-Boris
Received on Friday, 2 December 2016 16:23:44 UTC