Manages application of security headers with many safe defaults
MIT License
Bot releases are visible (Hide)
Published by oreoshake over 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.
Published by oreoshake over 8 years ago
Adds upgrade-insecure-requests
support for requests from Firefox and Chrome (and Opera). See the spec for details.
h/t @reedloden
Published by oreoshake over 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.
Published by oreoshake over 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.
Published by oreoshake over 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
Published by oreoshake over 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
Published by oreoshake almost 9 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.
Published by oreoshake almost 9 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'
Published by oreoshake almost 9 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.
Published by oreoshake almost 9 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
Published by oreoshake about 9 years ago
This release may change the output of headers based on per browser support. Unsupported directives will be omitted based on the user agent per request. See https://github.com/twitter/secureheaders/pull/179
p.s. this will likely be the last non-bugfix release for the 2.x line. 3.x will be a major change. Sneak preview: https://github.com/twitter/secureheaders/pull/181
Published by oreoshake about 9 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.
config.csp = {
:default_src => "'self'"
}
would produce default-src 'self'; connect-src 'self'; frame-src 'self' ... etc.
config.csp = {
:default_src => "'self'"
}
will produce default-src 'self'
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.
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.
Published by oreoshake about 9 years ago
See https://github.com/twitter/secureheaders/issues/167 and https://github.com/twitter/secureheaders/pull/168
tl;dr is that there is a class method SecureHeaders::header_hash
that will return a hash of header name => value pairs useful for merging with the rack header hash in middleware.
Published by oreoshake about 9 years ago
As discussed in https://github.com/twitter/secureheaders/issues/154
Published by oreoshake about 9 years ago
Published by oreoshake over 9 years ago
See https://github.com/twitter/secureheaders/pull/147
Allows you to override a controller method that returns a config in the context of the executing action.
Published by oreoshake over 9 years ago
See https://github.com/twitter/secureheaders/pull/150
Safari will generate a warning that it doesn't support nonces. Safari will fall back to the unsafe-inline
. Things will still work, but an ugly message is printed to the console.
This opts out safari and IE users from the inline script protection. I haven't verified any IE behavior yet, so I'm just assuming it doesn't work.
Published by oreoshake over 9 years ago
https://github.com/twitter/secureheaders/pull/148
Facilitates better per-request config:
:enforce => lambda { |controller| controller.current_user.beta_testing? }
NOTE if you used lambda
config values, this will raise an exception until you add the controller reference:
bad:
lambda { true }
good:
lambda { |controller| true }
proc { true }
proc { |controller| true }
Published by oreoshake over 9 years ago
Includes https://github.com/twitter/secureheaders/pull/143 (which is really just https://github.com/twitter/secureheaders/pull/132) from @thirstscolr
Published by oreoshake over 9 years ago
Just a small change that adds a constant that was missing as reported in https://github.com/twitter/secureheaders/issues/141