« Changelog History


SecureHeaders v2.4.0 Release Notes

Release Date: 2015-10-01 // over 8 years ago

  • ⚡️ 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'"
  }

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

    after

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

    0️⃣ will produce default-src 'self'

    0️⃣ 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

    0️⃣ 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.