Bug fix for regression

See #239

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.

Fix for `opt_out_of_all_protection` regression

See #235

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 Adding secure cookie support

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

Internal refactoring: In #232, 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.

Handle "fetch directives" when appending to a policy config

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(https://report-uri.io/asdf)
}

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

Bug fix release - frozen CSP configs can raise errors in some cases

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 #223.

Add upgrade-insecure-requests support

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

h/t @reedloden

Prepare for upcoming rails 5 changes related to filters

See #215

This should allow use of Rails 5 without deprecations from before_filter. before_filter is deprecated and will be removed in Rails 5.1.

This change is not applicable for the 3.x series.

3.x

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.

3.x rewrite release candidate

secure_headers 3.0 is a near-complete rewrite that is not entirely backwards compatible. See the upgrade guide for migrating between 2.x and 3.x: https://github.com/twitter/secureheaders/blob/master/upgrading-to-3-0.md

Remove noisy deprecation warning

See #203 and cfad0e5

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