All Versions
Latest Version
Avg Release Cycle
55 days
Latest Release

Changelog History
Page 5

  • v3.3.0 Changes

    ๐Ÿ‘ While not officially part of the spec and not implemented anywhere, support for the experimental referrer-policy header was preemptively added.

    โž• Additionally, two minor enhancements were added this version:

    1. Warn when the HPKP report host is the same as the current host. By definition any generated reports would be reporting to a known compromised connection. โš  1. Filter unsupported CSP directives when using Edge. Previously, this was causing many warnings in the developer console.
  • v3.2.0 Changes


    ๐Ÿ”ง SecureHeaders supports Secure, HttpOnly and SameSite cookies. These can be defined in the form of a boolean, or as a Hash for more refined configuration.

    Note: Regardless of the configuration specified, Secure cookies are only enabled for HTTPS requests.

    ๐Ÿ”ง Boolean-based configuration

    ๐Ÿ”ง Boolean-based configuration is intended to globally enable or disable a specific cookie attribute.

    config.cookies = {
      secure: true, # mark all cookies as Secure
      httponly: false, # do not mark any cookies as HttpOnly

    ๐Ÿ”ง Hash-based configuration

    ๐Ÿ”ง Hash-based configuration allows for fine-grained control.

    config.cookies = {
      secure: { except: ['_guest'] }, # mark all but the `_guest` cookie as Secure
      httponly: { only: ['_rails_session'] }, # only mark the `_rails_session` cookie as HttpOnly

    ๐Ÿ”ง SameSite cookie configuration

    SameSite cookies permit either Strict or Lax enforcement mode options.

    config.cookies = {
      samesite: {
        strict: true # mark all cookies as SameSite=Strict

    Strict and Lax enforcement modes can also be specified using a Hash.

    config.cookies = {
      samesite: {
        strict: { only: ['_rails_session'] },
        lax: { only: ['_guest'] }


    ๐Ÿ’… script/style-src hashes can be used to whitelist inline content that is static. This has the benefit of allowing inline content without opening up the possibility of dynamic javascript like you would with a nonce.

    You can add hash sources directly to your policy :

    ::SecureHeaders::Configuration.default do |config|
       config.csp = {
         default_src: %w('self')
         # this is a made up value but browsers will show the expected hash in the console.
         script_src: %w(sha256-123456)

    You can also use the automated inline script detection/collection/computation of hash source values in your app.

     rake secure_headers:generate_hashes

    This will generate a file (config/secure_headers_generated_hashes.yml by default, you can override by setting ENV["secure_headers_generated_hashes_file"]) containing a mapping of file names with the array of hash values found on that page. When ActionView renders a given file, we check if there are any known hashes for that given file. If so, they are added as values to the header.

      - "'sha256-yktKiAsZWmc8WpOyhnmhQoDf9G2dAZvuBBC+V0LGQhg='"
    ๐Ÿ’… styles:
      - "'sha256-SLp6LO3rrKDJwsG9uJUxZapb4Wp2Zhj6Bu3l+d9rnAY='"
      - "'sha256-HSGHqlRoKmHAGTAJ2Rq0piXX4CnEbOl1ArNd6ejp2TE='"

    This will not compute dynamic hashes by design. The output of both helpers will be a plain script/style tag without modification and the known hashes for a given file will be added to script-src/style-src when hashed_javascript_tag and hashed_style_tag are used. You can use raise_error_on_unrecognized_hash = true to be extra paranoid that you have precomputed hash values for all of your inline content. By default, this will raise an error in non-production environments.

    ๐Ÿ’… <%= hashed_style_tag do %>
    body {
      background-color: black;
    <% end %>
    ๐Ÿ’… <%= hashed_style_tag do %>
    body {
      font-size: 30px;
      font-color: green;
    <% end %>
    <%= hashed_javascript_tag do %>
    ๐ŸŒฒ console.log(1)
    <% end %>
    ๐Ÿ”’ Content-Security-Policy: ...
     script-src 'sha256-yktKiAsZWmc8WpOyhnmhQoDf9G2dAZvuBBC+V0LGQhg=' ... ;
     style-src 'sha256-SLp6LO3rrKDJwsG9uJUxZapb4Wp2Zhj6Bu3l+d9rnAY=' 'sha256-HSGHqlRoKmHAGTAJ2Rq0piXX4CnEbOl1ArNd6ejp2TE=' ...;
  • v3.1.2 Changes

    ๐Ÿ‘€ See

    This meant that when header caches were regenerated upon calling SecureHeaders.override(:name) and using it with use_secure_headers_override would result in default values for anything other than CSP/HPKP.

  • v3.1.1 Changes

    ๐Ÿ‘€ See

    โž• idempotent_additions? would return false when comparing OPT_OUT with OPT_OUT, causing header_hash_for to return a header cache with { nil => nil } which cause the middleware to blow up when { nil => nil } was merged into the rack header hash.

    This is a regression in 3.1.0 only.

    Now it returns true. I've added a test case to ensure that header_hash_for will never return such an element.

  • v3.1.0 Changes

    ๐Ÿ†• New feature: marking all cookies as secure. Added by @jmera in In the future, we'll probably add the ability to whitelist individual cookies that should not be marked secure. PRs welcome.

    ๐Ÿ”จ Internal refactoring: In, we changed the way dynamic CSP is handled internally. The biggest benefit is that highly dynamic policies (which can happen with multiple append/override calls per request) are handled better:

    1. Only the CSP header cache is busted when using a dynamic policy. All other headers are preserved and don't need to be generated. Dynamic X-Frame-Options changes modify the cache directly.
    2. Idempotency checks for policy modifications are deferred until the end of the request lifecycle and only happen once, instead of per append/override call. The idempotency check itself is fairly expensive itself.
    3. CSP header string is produced at most once per request.
  • v3.0.3 Changes

    ๐Ÿ› Bug fix for handling policy merges where appending a non-default source value (report-uri, plugin-types, frame-ancestors, base-uri, and form-action) would be combined with the default-src value. Appending a directive that doesn't exist in the current policy combines the new value with default-src to mimic the actual behavior of the addition. However, this does not make sense for non-default-src values (a.k.a. "fetch directives") and can lead to unexpected behavior like a report-uri value of *. Previously, this config:

      default_src => %w(*)

    When appending:

      report_uri => %w(

    Would result in default-src *; report-uri * which doesn't make any sense at all.

  • v3.0.2 Changes

    ๐Ÿ› Bug fix for handling CSP configs that supply a frozen hash. If a directive value is nil, then appending to a config with a frozen hash would cause an error since we're trying to modify a frozen hash. See

  • v3.0.1 Changes

    โž• Adds upgrade-insecure-requests support for requests from Firefox and Chrome (and Opera). See the spec for details.

  • v3.0.0 Changes

    โฌ†๏ธ secure_headers 3.0.0 is a near-complete, not-entirely-backward-compatible rewrite. Please see the upgrade guide for an in-depth explanation of the changes and the suggested upgrade path.

  • v2.5.1 Changes

    February 16, 2016

    ๐Ÿ‘€ See and

    โฌ†๏ธ >> Upon upgrading to secure_headers 2.5.0, I get a flood of these deprecations when running my tests:

    [DEPRECATION] secure_header_options_for will not be supported in secure_headers

    /cc @bquorning