@dankohn was seeing "already initialized" errors in his output. This change conditionally defines the constants.
@stefansundin noticed that supplying false to "boolean" CSP directives (e.g. upgrade-insecure-requests and block-all-mixed-content) would still include the value.
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:
- 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.
- Filter unsupported CSP directives when using Edge. Previously, this was causing many warnings in the developer console.
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 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 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 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)
}
endYou can also use the automated inline script detection/collection/computation of hash source values in your app.
rake secure_headers:generate_hashesThis will generate a file (config/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.
---
scripts:
app/views/asdfs/index.html.erb:
- "'sha256-yktKiAsZWmc8WpOyhnmhQoDf9G2dAZvuBBC+V0LGQhg='"
styles:
app/views/asdfs/index.html.erb:
- "'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=' ...;
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.
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.
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:
- 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.
- Idempotency checks for policy modifications are deferred until the end of the request lifecycle and only happen once, instead of per
append/overridecall. The idempotency check itself is fairly expensive itself. - CSP header string is produced at most once per request.
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 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.
Adds upgrade-insecure-requests support for requests from Firefox and Chrome (and Opera). See the spec for details.
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.
See #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
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.
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 #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'
@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.
A nasty regression meant that many CSP configuration values were "reset" after the first request, one of these being the "enforce" flag. See #184 for the full list of fields that were affected. Thanks to @spdawson for reporting this #183
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 #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: #181
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.
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.
As discussed in #154
2.2.3 - 2015-08-14 20:26:12 UTC - Adds ability to opt-out of automatically adding data: sources to img-src
See #161
See #147
Allows you to override a controller method that returns a config in the context of the executing action.
See #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.
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 }
Includes #143 (which is really just #132) from @thirstscolr
Just a small change that adds a constant that was missing as reported in #141
Fixes an issue where view helpers (for nonces, hashes, etc) weren't available in views.
This release contains support for more csp level 2 features such as the new directives, the script hash integration, and more.
It also sets a new header by default: X-Permitted-Cross-Domain-Policies
Support for hpkp is not included in this release as the implementations are still very unstable.
🚀
The only change between this and the first pre release is that the X-Permitted-Cross-Domain-Policies support is included.
This removes the forwarder and "experimental" feature. The forwarder wasn't well maintained and created a lot of headaches. Also, it was using an outdated certificate pack for compatibility. That's bad. The experimental feature wasn't really used and it complicated the codebase a lot. It's also a questionably useful API that is very confusing.
This release is intended to be ready for CSP level 2. Mainly, this means there is direct support for hash/nonce of inline content and includes many new directives (which do not inherit from default-src)
- Adds X-Download-Options support
- Adds support for X-XSS-Protection reporting
- Defers loading of rails engine for faster boot times
@agl just made a new option for HSTS representing confirmation that a site wants to be included in a browser's preload list (https://hstspreload.appspot.com).
This just adds a new 'preload' option to the HSTS settings to specify that option.
Tagging Requests
It's often valuable to send extra information in the report uri that is not available in the reports themselves. Namely, "was the policy enforced" and "where did the report come from"
{
:tag_report_uri => true,
:enforce => true,
:app_name => 'twitter',
:report_uri => 'csp_reports'
}Results in
report-uri csp_reports?enforce=true&app_name=twitter