Skip to content

Some internal changes affecting behavior, but not functionality

Compare
Choose a tag to compare
@oreoshake oreoshake released this 01 Oct 23:05

If you leveraged secure_headers automatic filling of empty directives, the header value will change but it should not affect how the browser applies the policy. The content of CSP reports may change if you do not update your policy.

before

  config.csp = {
    :default_src => "'self'"
  }

would produce default-src 'self'; connect-src 'self'; frame-src 'self' ... etc.

after

  config.csp = {
    :default_src => "'self'"
  }

will produce default-src 'self'

The reason for this is that a default-src violation was basically impossible to handle. Chrome sends an effective-directive which helps indicate what kind of violation occurred even if it fell back to default-src. This is part of the CSP Level 2 spec so hopefully other browsers will implement this soon.

Workaround

Just set the values yourself, but really a default-src of anything other than 'none' implies the policy can be tightened dramatically. "ZOMG don't you work for github and doesn't github send a default-src of *???" Yes, this is true. I disagree with this but at the same time, github defines every single known directive that a browser supports so default-src will only apply if a new directive is introduced, and we'd rather fail open. For now.

  config.csp = {
    :default_src => "'self'",
    :connect_src => "'self'",
    :frame_src => "'self'"
    ... etc.
  }

Besides, relying on default-src is often not what you want and encourages an overly permissive policy. I've seen it. Seriously. default-src 'unsafe-inline' 'unsafe-eval' https: http:; That's terrible.