Manages application of security headers with many safe defaults
MIT License
Bot releases are hidden (Show)
Published by KyFaSt about 1 year ago
Full Changelog: https://github.com/github/secure_headers/compare/v6.6.0...v6.7.0
Published by KyFaSt over 1 year ago
block-all-mixed-content
and replaced it with a recommendation to use the already supported upgrade-insecure-requests
instead.Published by lgarron over 2 years ago
https://github.com/github/secure_headers/blob/v6.3.4/CHANGELOG.md
Release notes:
For more details, see https://github.com/github/secure_headers/blob/v6.3.1/CHANGELOG.md
Published by lgarron over 2 years ago
Release notes:
For more details, see https://github.com/github/secure_headers/blob/v6.3.2/CHANGELOG.md
For more details, see https://github.com/github/secure_headers/blob/v6.3.3/CHANGELOG.md
Published by oreoshake almost 8 years ago
@solenko noticed an issue with the way the gem is loaded in rails 2 https://github.com/twitter/secureheaders/pull/304
Published by oreoshake almost 8 years ago
strict-dynamic
Published by oreoshake about 8 years ago
Published by oreoshake about 8 years ago
Handle the child-src
/frame-src
transition semi-intelligently across versions. I think the code best describes the behavior here:
if supported_directives.include?(:child_src)
@config[:child_src] = @config[:child_src] || @config[:frame_src]
else
@config[:frame_src] = @config[:frame_src] || @config[:child_src]
end
Published by oreoshake over 8 years ago
@dankohn was seeing "already initialized" errors in his output. This change conditionally defines the constants.
Published by oreoshake over 8 years ago
@stefansundin noticed that supplying false
to "boolean" CSP directives (e.g. upgrade-insecure-requests
and block-all-mixed-content
) would still include the value.
Published by oreoshake over 8 years ago
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:
Published by oreoshake over 8 years ago
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)
}
end
You can also use the automated inline script detection/collection/computation of hash source values in your app.
rake secure_headers:generate_hashes
This 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=' ...;
Published by oreoshake over 8 years ago
See https://github.com/twitter/secureheaders/pull/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.
Published by oreoshake over 8 years ago
See https://github.com/twitter/secureheaders/pull/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.
Published by oreoshake over 8 years ago
New feature: marking all cookies as secure. Added by @jmera in https://github.com/twitter/secureheaders/pull/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 https://github.com/twitter/secureheaders/pull/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:
append/override
call. The idempotency check itself is fairly expensive itself.Published by oreoshake over 8 years ago
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.
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