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
