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

Reply via email to