secure_headers 6.7.0 → 7.1.0

data/CONTRIBUTING.md

@@ -1,41 +0,0 @@
-## Contributing
-
-[fork]: https://github.com/twitter/secureheaders/fork
-[pr]: https://github.com/twitter/secureheaders/compare
-[style]: https://github.com/styleguide/ruby
-[code-of-conduct]: CODE_OF_CONDUCT.md
-
-Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.
-
-Please note that this project is released with a [Contributor Code of Conduct][code-of-conduct]. By participating in this project you agree to abide by its terms.
-
-## Submitting a pull request
-
-0. [Fork][fork] and clone the repository
-0. Configure and install the dependencies: `bundle install`
-0. Make sure the tests pass on your machine: `bundle exec rspec spec`
-0. Create a new branch: `git checkout -b my-branch-name`
-0. Make your change, add tests, and make sure the tests still pass and that no warnings are raised
-0. Push to your fork and [submit a pull request][pr]
-0. Pat your self on the back and wait for your pull request to be reviewed and merged.
-
-Here are a few things you can do that will increase the likelihood of your pull request being accepted:
-
-- Write tests.
-- Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
-- Write a [good commit message](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
-
-## Releasing
-
-0. Ensure CI is green
-0. Pull the latest code
-0. Increment the version
-0. Run `gem build secure_headers.gemspec`
-0. Bump the Gemfile and Gemfile.lock versions for an app which relies on this gem
-0. Test behavior locally, branch deploy, whatever needs to happen
-0. Run `bundle exec rake release`
-
-## Resources
-
-- [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
-- [Using Pull Requests](https://help.github.com/articles/about-pull-requests/)

data/Guardfile

@@ -1,13 +0,0 @@
-# frozen_string_literal: true
-guard :rspec, cmd: "bundle exec rspec", all_on_start: true, all_after_pass: true do
-  require "guard/rspec/dsl"
-  dsl = Guard::RSpec::Dsl.new(self)
-
-  # RSpec files
-  rspec = dsl.rspec
-  watch(rspec.spec_helper) { rspec.spec_dir }
-  watch(rspec.spec_support) { rspec.spec_dir }
-  watch(rspec.spec_files)
-
-  watch(%r{^lib/(.+)\.rb$}) { |m| "spec/lib/#{m[1]}_spec.rb" }
-end

data/Rakefile

@@ -1,32 +0,0 @@
-#!/usr/bin/env rake
-# frozen_string_literal: true
-require "bundler/gem_tasks"
-require "rspec/core/rake_task"
-require "net/http"
-require "net/https"
-
-RSpec::Core::RakeTask.new
-
-begin
-  require "rdoc/task"
-rescue LoadError
-  require "rdoc/rdoc"
-  require "rake/rdoctask"
-  RDoc::Task = Rake::RDocTask
-end
-
-begin
-  require "rubocop/rake_task"
-  RuboCop::RakeTask.new
-rescue LoadError
-  task(:rubocop) { $stderr.puts "RuboCop is disabled" }
-end
-
-RDoc::Task.new(:rdoc) do |rdoc|
-  rdoc.rdoc_dir = "rdoc"
-  rdoc.title    = "SecureHeaders"
-  rdoc.options << "--line-numbers"
-  rdoc.rdoc_files.include("lib/**/*.rb")
-end
-
-task default: [:spec, :rubocop]

data/docs/cookies.md

@@ -1,65 +0,0 @@
-## Cookies
-
-SecureHeaders supports `Secure`, `HttpOnly` and [`SameSite`](https://tools.ietf.org/html/draft-west-first-party-cookies-07) 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.
-
-#### Defaults
-
-By default, all cookies will get both `Secure`, `HttpOnly`, and `SameSite=Lax`.
-
-```ruby
-config.cookies = {
-  secure: true, # defaults to true but will be a no op on non-HTTPS requests
-  httponly: true, # defaults to true
-  samesite: {  # defaults to set `SameSite=Lax`
-    lax: true
-  }
-}
-```
-
-#### Boolean-based configuration
-
-Boolean-based configuration is intended to globally enable or disable a specific cookie attribute. *Note: As of 4.0, you must use OPT_OUT rather than false to opt out of the defaults.*
-
-```ruby
-config.cookies = {
-  secure: true, # mark all cookies as Secure
-  httponly: SecureHeaders::OPT_OUT, # do not mark any cookies as HttpOnly
-}
-```
-
-#### Hash-based configuration
-
-Hash-based configuration allows for fine-grained control.
-
-```ruby
-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.
-
-```ruby
-config.cookies = {
-  samesite: {
-    strict: true # mark all cookies as SameSite=Strict
-  }
-}
-```
-
-`Strict`, `Lax`, and `None` enforcement modes can also be specified using a Hash.
-
-```ruby
-config.cookies = {
-  samesite: {
-    strict: { only: ['session_id_duplicate'] },
-    lax: { only: ['_guest', '_rails_session', 'device_id'] },
-    none: { only: ['_tracking', 'saml_cookie', 'session_id'] },
-  }
-}
-```

data/docs/hashes.md

@@ -1,64 +0,0 @@
-## Hash
-
-`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 :
-
-```ruby
-::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)
-   }
- end
- ```
-
- You can also use the automated inline script detection/collection/computation of hash source values in your app.
-
- ```bash
- 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.
-
-```yaml
----
-scripts:
-  app/views/asdfs/index.html.erb:
-  - "'sha256-yktKiAsZWmc8WpOyhnmhQoDf9G2dAZvuBBC+V0LGQhg='"
-styles:
-  app/views/asdfs/index.html.erb:
-  - "'sha256-SLp6LO3rrKDJwsG9uJUxZapb4Wp2Zhj6Bu3l+d9rnAY='"
-  - "'sha256-HSGHqlRoKmHAGTAJ2Rq0piXX4CnEbOl1ArNd6ejp2TE='"
-```
-
-##### Helpers
-
-**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.
-
-```erb
-<%= 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=' ...;
-```

data/docs/named_overrides_and_appends.md

@@ -1,104 +0,0 @@
-## Named Appends
-
-Named Appends are blocks of code that can be reused and composed during requests. e.g. If a certain partial is rendered conditionally, and the csp needs to be adjusted for that partial, you can create a named append for that situation. The value returned by the block will be passed into `append_content_security_policy_directives`. The current request object is passed as an argument to the block for even more flexibility. Reusing a configuration name is not allowed and will throw an exception.
-
-```ruby
-def show
-  if include_widget?
-    @widget = widget.render
-    use_content_security_policy_named_append(:widget_partial)
-  end
-end
-
-
-SecureHeaders::Configuration.named_append(:widget_partial) do |request|
-  SecureHeaders.override_x_frame_options(request, "DENY")
-  if request.controller_instance.current_user.in_test_bucket?
-    { child_src: %w(beta.thirdpartyhost.com) }
-  else
-    { child_src: %w(thirdpartyhost.com) }
-  end
-end
-```
-
-You can use as many named appends as you would like per request, but be careful because order of inclusion matters. Consider the following:
-
-```ruby
-SecureHeader::Configuration.default do |config|
-  config.csp = { default_src: %w('self')}
-end
-
-SecureHeaders::Configuration.named_append(:A) do |request|
-  { default_src: %w(myhost.com) }
-end
-
-SecureHeaders::Configuration.named_append(:B) do |request|
-  { script_src: %w('unsafe-eval') }
-end
-```
-
-The following code will produce different policies due to the way policies are normalized (e.g. providing a previously undefined directive that inherits from `default-src`, removing host source values when `*` is provided. Removing `'none'` when additional values are present, etc.):
-
-```ruby
-def index
-  use_content_security_policy_named_append(:A)
-  use_content_security_policy_named_append(:B)
-  # produces default-src 'self' myhost.com; script-src 'self' myhost.com 'unsafe-eval';
-end
-
-def show
-  use_content_security_policy_named_append(:B)
-  use_content_security_policy_named_append(:A)
-  # produces default-src 'self' myhost.com; script-src 'self' 'unsafe-eval';
-end
-```
-
-
-## Named overrides
-
-Named overrides serve two purposes:
-
-* To be able to refer to a configuration by simple name.
-* By precomputing the headers for a named configuration, the headers generated once and reused over every request.
-
-To use a named override, drop a `SecureHeaders::Configuration.override` block **outside** of method definitions and then declare which named override you'd like to use. You can even override an override.
-
-```ruby
-class ApplicationController < ActionController::Base
-  SecureHeaders::Configuration.default do |config|
-    config.csp = {
-      default_src: %w('self'),
-      script_src: %w(example.org)
-    }
-  end
-
-  # override default configuration
-  SecureHeaders::Configuration.override(:script_from_otherdomain_com) do |config|
-    config.csp[:script_src] << "otherdomain.com"
-  end
-end
-
-class MyController < ApplicationController
-  def index
-    # Produces default-src 'self'; script-src example.org otherdomain.com
-    use_secure_headers_override(:script_from_otherdomain_com)
-  end
-
-  def show
-    # Produces default-src 'self'; script-src example.org otherdomain.org evenanotherdomain.com
-    use_secure_headers_override(:another_config)
-  end
-end
-```
-
-Reusing a configuration name is not allowed and will throw an exception.
-
-By default, a no-op configuration is provided. No headers will be set when this default override is used.
-
-```ruby
-class MyController < ApplicationController
-  def index
-    SecureHeaders.opt_out_of_all_protection(request)
-  end
-end
-```

data/docs/per_action_configuration.md

@@ -1,139 +0,0 @@
-## Per-action configuration
-
-You can override the settings for a given action by producing a temporary override. Be aware that because of the dynamic nature of the value, the header values will be computed per request.
-
-```ruby
-# Given a config of:
-::SecureHeaders::Configuration.default do |config|
-   config.csp = {
-     default_src: %w('self'),
-     script_src: %w('self')
-   }
- end
-
-class MyController < ApplicationController
-  def index
-    # Append value to the source list, override 'none' values
-    # Produces: default-src 'self'; script-src 'self' s3.amazonaws.com; object-src 'self' www.youtube.com
-    append_content_security_policy_directives(script_src: %w(s3.amazonaws.com), object_src: %w('self' www.youtube.com))
-
-    # Overrides the previously set source list, override 'none' values
-    # Produces: default-src 'self'; script-src s3.amazonaws.com; object-src 'self'
-    override_content_security_policy_directives(script_src: %w(s3.amazonaws.com), object_src: %w('self'))
-
-    # Global settings default to "sameorigin"
-    override_x_frame_options("DENY")
-  end
-```
-
-The following methods are available as controller instance methods. They are also available as class methods, but require you to pass in the `request` object.
-* `append_content_security_policy_directives(hash)`: appends each value to the corresponding CSP app-wide configuration.
-* `override_content_security_policy_directives(hash)`: merges the hash into the app-wide configuration, overwriting any previous config
-* `override_x_frame_options(value)`: sets the `X-Frame-Options header` to `value`
-
-## Appending / overriding Content Security Policy
-
-When manipulating content security policy, there are a few things to consider. The default header value is `default-src https:` which corresponds to a default configuration of `{ default_src: %w(https:)}`.
-
-#### Append to the policy with a directive other than `default_src`
-
-The value of `default_src` is joined with the addition if the it is a [fetch directive](https://w3c.github.io/webappsec-csp/#directives-fetch). Note the `https:` is carried over from the `default-src` config. If you do not want this, use `override_content_security_policy_directives` instead. To illustrate:
-
-```ruby
-::SecureHeaders::Configuration.default do |config|
-   config.csp = {
-     default_src: %w('self')
-   }
- end
- ```
-
-Code  | Result
-------------- | -------------
-`append_content_security_policy_directives(script_src: %w(mycdn.com))` | `default-src 'self'; script-src 'self' mycdn.com`
-`override_content_security_policy_directives(script_src: %w(mycdn.com))`  | `default-src 'self'; script-src mycdn.com`
-
-#### Nonce
-
-You can use a view helper to automatically add nonces to script tags. Currently, using a nonce helper or calling `content_security_policy_nonce` will populate all configured CSP headers, including report-only and enforced policies. 
-
-```erb
-<%= nonced_javascript_tag do %>
-console.log("nonced!");
-<% end %>
-
-<%= nonced_style_tag do %>
-body {
-  background-color: black;
-}
-<% end %>
-
-<%= nonced_javascript_include_tag "include.js" %>
-
-<%= nonced_javascript_pack_tag "pack.js" %>
-
-<%= nonced_stylesheet_link_tag "link.css" %>
-
-<%= nonced_stylesheet_pack_tag "pack.css" %>
-```
-
-becomes:
-
-```html
-<script nonce="/jRAxuLJsDXAxqhNBB7gg7h55KETtDQBXe4ZL+xIXwI=">
-console.log("nonced!")
-</script>
-<style nonce="/jRAxuLJsDXAxqhNBB7gg7h55KETtDQBXe4ZL+xIXwI=">
-body {
-  background-color: black;
-}
-</style>
-```
-
-```
-
-Content-Security-Policy: ...
-  script-src 'nonce-/jRAxuLJsDXAxqhNBB7gg7h55KETtDQBXe4ZL+xIXwI=' ...;
-  style-src 'nonce-/jRAxuLJsDXAxqhNBB7gg7h55KETtDQBXe4ZL+xIXwI=' ...;
-```
-
-`script`/`style-nonce` can be used to whitelist inline content. To do this, call the `content_security_policy_script_nonce` or `content_security_policy_style_nonce` then set the nonce attributes on the various tags.
-
-```erb
-<script nonce="<%= content_security_policy_script_nonce %>">
-  console.log("whitelisted, will execute")
-</script>
-
-<script nonce="lol">
-  console.log("won't execute, not whitelisted")
-</script>
-
-<script>
-  console.log("won't execute, not whitelisted")
-</script>
-```
-
-## Clearing browser cache
-
-You can clear the browser cache after the logout request by using the following.
-
-``` ruby
-class ApplicationController < ActionController::Base
-  # Configuration override to send the Clear-Site-Data header.
-  SecureHeaders::Configuration.override(:clear_browser_cache) do |config|
-    config.clear_site_data = SecureHeaders::ClearSiteData::ALL_TYPES
-  end
-
-
-  # Clears the browser's cache for browsers supporting the Clear-Site-Data
-  # header.
-  #
-  # Returns nothing.
-  def clear_browser_cache
-    SecureHeaders.use_secure_headers_override(request, :clear_browser_cache)
-  end
-end
-
-class SessionsController < ApplicationController
-  after_action  :clear_browser_cache, only: :destroy
-end
-```

data/docs/sinatra.md

@@ -1,25 +0,0 @@
-## Sinatra
-
-Here's an example using SecureHeaders for Sinatra applications:
-
-```ruby
-require 'rubygems'
-require 'sinatra'
-require 'haml'
-require 'secure_headers'
-
-use SecureHeaders::Middleware
-
-SecureHeaders::Configuration.default do |config|
-  ...
-end
-
-class Donkey < Sinatra::Application
-  set :root, APP_ROOT
-
-  get '/' do
-    SecureHeaders.override_x_frame_options(request, SecureHeaders::OPT_OUT)
-    haml :index
-  end
-end
-```

data/docs/upgrading-to-3-0.md

@@ -1,42 +0,0 @@
-`secure_headers` 3.0 is a near-complete rewrite. It includes breaking changes and removes a lot of features that were either leftover from the days when the CSP standard was not fully adopted or were just downright confusing.
-
-Changes
-==
-
-| What                                                     | < = 2.x                                                                                                                                                                                         | >= 3.0                                                                                                                                                                       |
-| ----------------------------------                       | ----------------------------------------------------------                                                                                                                                      | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Global configuration                                     | `SecureHeaders::Configuration.configure` block                                                                                                                                                  | `SecureHeaders::Configuration.default` block                                                                                                                                 |
-| All headers besides HPKP and CSP                         | Accept hashes as config values                                                                                                                                                                  | Must be strings (validated during configuration)                                                                                                                             |
-| CSP directive values                                     | Accepted space delimited strings OR arrays of strings                                                                                                                                           | Must be arrays of strings                                                                                                                                                    |
-| CSP Nonce values in views                                | `@content_security_policy_nonce`                                                                                                                                                                | `content_security_policy_nonce(:script)` or `content_security_policy_nonce(:style)`                                                                                              |
-| nonce is no longer a source expression                   | `config.csp = "'self' 'nonce'"`                                                                                                                                                                 | Remove `'nonce'` from source expression and use [nonce helpers](https://github.com/twitter/secureheaders#nonce).                                                             |
-| `self`/`none` source expressions                         | Could be `self` / `none` / `'self'` / `'none'`                                                                                                                                                  | Must be `'self'` or `'none'`                                                                                                                                                 |
-| `inline` / `eval` source expressions                     | Could be `inline`, `eval`, `'unsafe-inline'`, or `'unsafe-eval'`                                                                                                                                | Must be `'unsafe-eval'` or `'unsafe-inline'`                                                                                                                                 |
-| Per-action configuration                                 | Override [`def secure_header_options_for(header, options)`](https://github.com/twitter/secureheaders/commit/bb9ebc6c12a677aad29af8e0f08ffd1def56efec#diff-04c6e90faac2675aa89e2176d2eec7d8R111) | Use [named overrides](https://github.com/twitter/secureheaders#named-overrides) or [per-action helpers](https://github.com/twitter/secureheaders#per-action-configuration)   |
-| CSP/HPKP use `report_only` config that defaults to false | `enforce: false`                                                                                                                                                                                | `report_only: false`                                                                                                                                                         |
-| Schemes in source expressions                            | Schemes were not stripped                                                                                                                                                                       | Schemes are stripped by default to discourage mixed content. Setting `preserve_schemes: true` will revert to previous behavior                                               |
-| Opting out of default configuration                      | `skip_before_filter :set_x_download_options_header` or `config.x_download_options = false`                                                                                                      | Within default block: `config.x_download_options = SecureHeaders::OPT_OUT`                                                                                                   |
-
-Migrating to 3.x from <= 2.x
-==
-
-1. Convert all headers except for CSP/HPKP using hashes to string values. The values are validated at runtime and will provide guidance on misconfigured headers.
-1. Convert all instances of `self`/`none`/`eval`/`inline` to the corresponding values in the above table.
-1. Convert all CSP space-delimited directives to an array of strings.
-1. Convert all `enforce: true|false` to `report_only: true|false`. 
-1. Remove `ensure_security_headers` from controllers (3.x uses a middleware instead).
-
-Everything is terrible, why should I upgrade?
-==
-
-`secure_headers` <= 2.x built every header per request using a series of automatically included `before_filters`. This is horribly inefficient because:
-
-1. `before_filters` are slow and adding 8 per request isn't great
-1. We are rebuilding strings that may never change for every request
-1. Errors in the request may mean that the headers never get set in the first place
-
-`secure_headers` 3.x sets headers in rack middleware that runs once per request and uses configuration values passed via `request.env`. This is much more efficient and somewhat guarantees that headers will always be set. **The values for the headers are cached and reused per request**.
-
-Also, there is a more flexible API for customizing content security policies / X-Frame-Options. In practice, none of the other headers need granular controls. One way of customizing headers per request is to use the helper methods. The only downside of this technique is that headers will be computed from scratch.
-
-See the [README](README.md) for more information.

data/docs/upgrading-to-4-0.md

@@ -1,35 +0,0 @@
-## script_src must be set
-
-Not setting a `script_src` value means your policy falls back to whatever `default_src` (also required) is set to. This can be very dangerous and indicates the policy is too loose.
-
-However, sometimes you really don't need a `script-src` e.g. API responses (`default-src 'none'`) so you can set `script_src: SecureHeaders::OPT_OUT` to work around this.
-
-## Default Content Security Policy
-
-The default CSP has changed to be more universal without sacrificing too much security.
-
-* Flash/Java disabled by default
-* `img-src` allows data: images and favicons (among others)
-* `style-src` allows inline CSS by default (most find it impossible/impractical to remove inline content today)
-* `form-action` (not governed by `default-src`, practically treated as `*`) is set to `'self'`
-
-Previously, the default CSP was:
-
-`Content-Security-Policy: default-src 'self'`
-
-The new default policy is:
-
-`default-src https:; form-action 'self'; img-src https: data: 'self'; object-src 'none'; script-src https:; style-src 'self' 'unsafe-inline' https:`
-
-## CSP configuration
-
-* Setting `report_only: true` in a CSP config will raise an error. Instead, set `csp_report_only`.
-* Setting `frame_src` and `child_src` when values don't match will raise an error. Just use `frame_src`.
-
-## config.secure_cookies removed
-
-Use `config.cookies` instead.
-
-## Supported ruby versions
-
-We've dropped support for ruby versions <= 2.2. Sorry.

data/docs/upgrading-to-5-0.md

@@ -1,15 +0,0 @@
-## All cookies default to secure/httponly/SameSite=Lax
-
-By default, *all* cookies will be marked as `SameSite=lax`,`secure`, and `httponly`. To opt-out, supply `SecureHeaders::OPT_OUT` as the value for `SecureHeaders.cookies` or the individual configs. Setting these values to `false` will raise an error.
-
-```ruby
-# specific opt outs
-config.cookies = {
-  secure: SecureHeaders::OPT_OUT,
-  httponly: SecureHeaders::OPT_OUT,
-  samesite: SecureHeaders::OPT_OUT,
-}
-
-# nuclear option, just make things work again
-config.cookies = SecureHeaders::OPT_OUT
-```

data/docs/upgrading-to-6-0.md

@@ -1,50 +0,0 @@
-## Named overrides are now dynamically applied
-
-The original implementation of name overrides worked by making a copy of the default policy, applying the overrides, and storing the result for later use. But, this lead to unexpected results if named overrides were combined with a dynamic policy change. If a change was made to the default configuration during a request, followed by a named override, the dynamic changes would be lost. To keep things consistent named overrides have been rewritten to work the same as named appends in that they always operate on the configuration for the current request. As an example:
-
-```ruby
-class ApplicationController < ActionController::Base
-  Configuration.default do |config|
-    config.x_frame_options = SecureHeaders::OPT_OUT
-  end
-
-  SecureHeaders::Configuration.override(:dynamic_override) do |config|
-    config.x_content_type_options = "nosniff"
-  end
-end
-
-class FooController < ApplicationController
-  def bar
-    # Dynamically update the default config for this request
-    override_x_frame_options("DENY")
-    append_content_security_policy_directives(frame_src: "3rdpartyprovider.com")
-
-    # Override everything, discard modifications above
-    use_secure_headers_override(:dynamic_override)
-  end
-end
-```
-
-Prior to 6.0.0, the response would NOT include a `X-Frame-Options` header since the named override would be a copy of the default configuration, but with `X-Content-Type-Options` set to `nosniff`. As of 6.0.0, the above code results in both `X-Frame-Options` set to `DENY` AND `X-Content-Type-Options` set to `nosniff`.
-
-## `ContentSecurityPolicyConfig#merge` and `ContentSecurityPolicyReportOnlyConfig#merge` work more like `Hash#merge`
-
-These classes are typically not directly instantiated by users of SecureHeaders. But, if you access `config.csp` you end up accessing one of these objects. Prior to 6.0.0, `#merge` worked more like `#append` in that it would combine policies (i.e. if both policies contained the same key the values would be combined rather than overwritten). This was not consistent with `#merge!`, which worked more like Ruby's `Hash#merge!` (overwriting duplicate keys). As of 6.0.0, `#merge` works the same as `#merge!`, but returns a new object instead of mutating `self`.
-
-## `Configuration#get` has been removed
-
-This method is not typically directly called by users of SecureHeaders. Given that named overrides are no longer statically stored, fetching them no longer makes sense.
-
-## Configuration headers are no longer cached
-
-Prior to 6.0.0 SecureHeaders pre-built and cached the headers that corresponded to the default configuration. The same was also done for named overrides. However, now that named overrides are applied dynamically, those can no longer be cached. As a result, caching has been removed in the name of simplicity. Some micro-benchmarks indicate this shouldn't be a performance problem and will help to eliminate a class of bugs entirely.
-
-## Calling the default configuration more than once will result in an Exception
-
-Prior to 6.0.0 you could conceivably, though unlikely, have `Configure#default` called more than once. Because configurations are dynamic, configuring more than once could result in unexpected behavior. So, as of 6.0.0 we raise `AlreadyConfiguredError` if the default configuration is setup more than once.
-
-## All user agent sniffing has been removed
-
-The policy configured is the policy that is delivered in terms of which directives are sent. We still dedup, strip schemes, and look for other optimizations but we will not e.g. conditionally send `frame-src` / `child-src` or apply `nonce`s / `unsafe-inline`.
-
-The primary reason for these per-browser customization was to reduce console warnings. This has lead to many bugs and results in confusing behavior. Also, console logs are incredibly noisy today and increasingly warn you about perfectly valid things (like sending `X-Frame-Options` and `frame-ancestors` together).