Secure Headers Versions Save

Manages application of security headers with many safe defaults

v3.0.2

8 years ago

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 https://github.com/twitter/secureheaders/pull/223.

v3.0.1

8 years ago

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

h/t @reedloden

v.2.5.2

8 years ago

See https://github.com/twitter/secureheaders/pull/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.

v3.0.0

8 years ago

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.

v3.0.0.rc1

8 years ago

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

2.5.1

8 years ago

See https://github.com/twitter/secureheaders/issues/203 and https://github.com/twitter/secureheaders/commit/cfad0e52285353b88e46fe384e7cd60bf2a01735

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

2.5.0

8 years ago

This release contains deprecation warnings for those wishing to upgrade to the 3.x series. With this release, fixing all deprecation warnings will make your configuration compatible when you decide to upgrade to the soon-to-be-released 3.x series (currently in pre-release stage).

No changes to functionality should be observed unless you were using procs as CSP config values.

2.4.4

8 years ago

If you use the header_hash method for setting your headers in middleware and you opted out of a header (via setting the value to false), you would run into an exception as described in https://github.com/twitter/secureheaders/pull/193

     NoMethodError:
       undefined method `name' for nil:NilClass
     # ./lib/secure_headers.rb:63:in `block in header_hash'
     # ./lib/secure_headers.rb:54:in `each'
     # ./lib/secure_headers.rb:54:in `inject'
     # ./lib/secure_headers.rb:54:in `header_hash'

2.4.3

8 years ago

@igrep reported an anti-patter in use regarding UserAgentParser. This caused UserAgentParser to reload it's entire configuration set twice* per request. Moving this to a cached constant prevents the constant reinstantiation and will improve performance.

https://github.com/twitter/secureheaders/issues/187

2.4.2

8 years ago

A nasty regression meant that many CSP configuration values were "reset" after the first request, one of these being the "enforce" flag. See https://github.com/twitter/secureheaders/pull/184 for the full list of fields that were affected. Thanks to @spdawson for reporting this https://github.com/twitter/secureheaders/issues/183