secure_headers 3.0.3 → 4.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 8ce791545252f765e19db9b42b88d0dec3c7f14a
-  data.tar.gz: 5a677c30789119f527ea04f940de663a98344339
+  metadata.gz: de4e0f18558ac4a65a9983f56e4dd65ca95e5f82
+  data.tar.gz: 3c16a5bdeec36aab812bcbfbbdba544b969c3a33
 SHA512:
-  metadata.gz: c861e7c69de1e69d4a53090a33b9c2f699900ee728d55694f0e7df7c32f430bebc65a9304cf0a8536c4663ed97c678340065a17a1ce6862c000b1c7984989d29
-  data.tar.gz: cc33e4d244bbd8bdc46960594d5d6de0bae38bcac6b282f5be9a8a32807d6ad2eb737e28553335cc74223a8ede8c6d592207bd5ee168fb05bf91c04118c8ec69
+  metadata.gz: 14f3bc42066b1b4bd6044b75a78818a6ce6edc60760e84af03d13623758a4d05b9397d0c4b4baa92c71d105e0334fa39ec56124c3014e8a63096236f9c6e6d51
+  data.tar.gz: f07cfc4d11b24a7d7ec1ad50b2fb756fd3a69c8558b922eb79daf35bbf5dc721c24ca27dfa8b5ca13865dc3345cb0162161f3c41fa04ffbff8c190908d8a7b32

data/.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,41 @@
+# Feature Requests
+
+## Adding a new header
+
+Generally, adding a new header is always OK. 
+
+* Is the header supported by any user agent? If so, which?
+* What does it do?
+* What are the valid values for the header?
+* Where does the specification live?
+
+## Adding a new CSP directive
+
+* Is the directive supported by any user agent? If so, which?
+* What does it do?
+* What are the valid values for the directive?
+
+---
+
+# Bugs
+
+Console errors and deprecation warnings are considered bugs that should be addressed with more precise UA sniffing. Bugs caused by incorrect or invalid UA sniffing are also bugs.
+
+### Expected outcome
+
+Describe what you expected to happen 
+
+1. I configure CSP to do X
+1. When I inspect the response headers, the CSP should have included X
+
+### Actual outcome
+
+1. The generated policy did not include X
+
+### Config
+
+Please provide the configuration (`SecureHeaders::Configuration.default`) you are using including any overrides (`SecureHeaders::Configuration.override`).
+
+### Generated headers
+
+Provide a sample response containing the headers

data/.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,20 @@
+## All PRs:
+
+* [ ] Has tests
+* [ ] Documentation updated
+
+## Adding a new header
+
+Generally, adding a new header is always OK.
+
+* Is the header supported by any user agent? If so, which?
+* What does it do?
+* What are the valid values for the header?
+* Where does the specification live?
+
+## Adding a new CSP directive
+
+* Is the directive supported by any user agent? If so, which?
+* What does it do?
+* What are the valid values for the directive?
+

data/.gitignore

@@ -6,17 +6,8 @@
 .yardoc
 *.log
 Gemfile.lock
-InstalledFiles
 _yardoc
 coverage
-doc/
-lib/bundler/man
 pkg
 rdoc
 spec/reports
-test/tmp
-test/version_tmp
-*tmp
-*.sqlite3
-fixtures/rails_3_2_12_no_init/log
-fixtures/rails_3_2_12/log

data/.rspec

@@ -1 +1,3 @@
 --order rand
+--warnings
+--format progress

data/.rubocop.yml

@@ -0,0 +1,3 @@
+inherit_gem:
+  rubocop-github:
+    - config/default.yml

data/.ruby-version

@@ -1 +1 @@
-2.2.3
+2.4.1

data/.travis.yml

@@ -1,13 +1,25 @@
 language: ruby
 
 rvm:
-  - "2.2"
-  - "2.1"
-  - "2.0.0"
-  - "1.9.3"
-  - "jruby-19mode"
+  - ruby-head
+  - 2.4.1
+  - 2.3.4
+  - 2.2
+  - jruby-head
+
+env:
+  - SUITE=rspec spec
+  - SUITE=rubocop
+
+script: bundle exec $SUITE
+
+matrix:
+  allow_failures:
+    - rvm: jruby-head
+    - rvm: ruby-head
 
 before_install: gem update bundler
+bundler_args: --without guard -j 3
 
 sudo: false
 cache: bundler

data/CHANGELOG.md

@@ -1,3 +1,289 @@
+## 4.x
+
+- See the [upgrading to 4.0](upgrading-to-4-0.md) guide. Lots of breaking changes.
+
+## 3.7.1
+
+Fix support for the sandbox attribute of CSP. `true` and `[]` represent the maximally restricted policy (`sandbox;`) and validate other values.
+
+## 3.7.0
+
+Adds support for the `Expect-CT` header (@jacobbednarz: https://github.com/twitter/secureheaders/pull/322)
+
+## 3.6.7
+
+Actually set manifest-src when configured. https://github.com/twitter/secureheaders/pull/339 Thanks @carlosantoniodasilva!
+
+## 3.6.5
+
+Update clear-site-data header to use current format specified by the specification.
+
+## 3.6.4
+
+Fix case where mixing frame-src/child-src dynamically would behave in unexpected ways: https://github.com/twitter/secureheaders/pull/325
+
+## 3.6.3
+
+Remove deprecation warning when setting `frame-src`. It is no longer deprecated.
+
+## 3.6.2
+
+Now that Safari 10 supports nonces and it appears to work, enable the nonce feature for safari.
+
+## 3.6.1
+
+Improved memory use via minor improvements clever hacks that are sadly needed.
+Thanks @carlosantoniodasilva!
+
+## 3.6.0
+
+Add support for the clear-site-data header
+
+## 3.5.1
+
+* Fix bug that can occur when useragent library version is older, resulting in a nil version sometimes.
+* Add constant for `strict-dynamic`
+
+## 3.5.0
+
+This release adds support for setting two CSP headers (enforced/report-only) and management around them.
+
+
+## 3.4.1 Named Appends
+
+### Small bugfix
+
+If your CSP did not define a script/style-src and you tried to use a script/style nonce, the nonce would be added to the page but it would not be added to the CSP. A workaround is to define a script/style src but now it should add the missing directive (and populate it with the default-src).
+
+### Named Appends
+
+Named Appends are blocks of code that can be reused and composed during requests. e.g. If a certain partial is rendered conditionally, and the csp needs to be adjusted for that partial, you can create a named append for that situation. The value returned by the block will be passed into `append_content_security_policy_directives`. The current request object is passed as an argument to the block for even more flexibility.
+
+```ruby
+def show
+  if include_widget?
+    @widget = widget.render
+    use_content_security_policy_named_append(:widget_partial)
+  end
+end
+
+
+SecureHeaders::Configuration.named_append(:widget_partial) do |request|
+  if request.controller_instance.current_user.in_test_bucket?
+    SecureHeaders.override_x_frame_options(request, "DENY")
+    { child_src: %w(beta.thirdpartyhost.com) }
+  else
+    { child_src: %w(thirdpartyhost.com) }
+  end
+end
+```
+
+You can use as many named appends as you would like per request, but be careful because order of inclusion matters. Consider the following:
+
+```ruby
+SecureHeader::Configuration.default do |config|
+  config.csp = { default_src: %w('self')}
+end
+
+SecureHeaders::Configuration.named_append(:A) do |request|
+  { default_src: %w(myhost.com) }
+end
+
+SecureHeaders::Configuration.named_append(:B) do |request|
+  { script_src: %w('unsafe-eval') }
+end
+```
+
+The following code will produce different policies due to the way policies are normalized (e.g. providing a previously undefined directive that inherits from `default-src`, removing host source values when `*` is provided. Removing `'none'` when additional values are present, etc.):
+
+```ruby
+def index
+  use_content_security_policy_named_append(:A)
+  use_content_security_policy_named_append(:B)
+  # produces default-src 'self' myhost.com; script-src 'self' myhost.com 'unsafe-eval';
+end
+
+def show
+  use_content_security_policy_named_append(:B)
+  use_content_security_policy_named_append(:A)
+  # produces default-src 'self' myhost.com; script-src 'self' 'unsafe-eval';
+end
+```
+
+## 3.4.0 the frame-src/child-src transition for Firefox.
+
+Handle the `child-src`/`frame-src` transition semi-intelligently across versions. I think the code best descibes the behavior here:
+
+```ruby
+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
+```
+
+Also, @koenpunt noticed that we were [loading view helpers](https://github.com/twitter/secureheaders/pull/272) in a way that Rails 5 did not like.
+
+## 3.3.2 minor fix to silence warnings when using rake
+
+[@dankohn](https://github.com/twitter/secureheaders/issues/257) was seeing "already initialized" errors in his output. This change conditionally defines the constants.
+
+## 3.3.1 bugfix for boolean CSP directives
+
+[@stefansundin](https://github.com/twitter/secureheaders/pull/253) noticed that supplying `false` to "boolean" CSP directives (e.g. `upgrade-insecure-requests` and `block-all-mixed-content`) would still include the value.
+
+## 3.3.0 referrer-policy support
+
+While not officially part of the spec and not implemented anywhere, support for the experimental [`referrer-policy` header](https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-header) was [preemptively added](https://github.com/twitter/secureheaders/pull/249).
+
+Additionally, two minor enhancements were added this version:
+1. [Warn when the HPKP report host is the same as the current host](https://github.com/twitter/secureheaders/pull/246). By definition any generated reports would be reporting to a known compromised connection.
+1. [Filter unsupported CSP directives when using Edge](https://github.com/twitter/secureheaders/pull/247). Previously, this was causing many warnings in the developer console.
+
+## 3.2.0 Cookie settings and CSP hash sources
+
+### Cookies
+
+SecureHeaders supports `Secure`, `HttpOnly` and [`SameSite`](https://tools.ietf.org/html/draft-west-first-party-cookies-07) 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
+
+Boolean-based configuration is intended to globally enable or disable a specific cookie attribute.
+
+```ruby
+config.cookies = {
+  secure: true, # mark all cookies as Secure
+  httponly: false, # do not mark any cookies as HttpOnly
+}
+```
+
+#### Hash-based configuration
+
+Hash-based configuration allows for fine-grained control.
+
+```ruby
+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 cookie configuration
+
+SameSite cookies permit either `Strict` or `Lax` enforcement mode options.
+
+```ruby
+config.cookies = {
+  samesite: {
+    strict: true # mark all cookies as SameSite=Strict
+  }
+}
+```
+
+`Strict` and `Lax` enforcement modes can also be specified using a Hash.
+
+```ruby
+config.cookies = {
+  samesite: {
+    strict: { only: ['_rails_session'] },
+    lax: { only: ['_guest'] }
+  }
+}
+```
+
+#### Hash
+
+`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 :
+
+```ruby
+::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.
+
+ ```bash
+ rake secure_headers:generate_hashes
+ ```
+
+ This will generate a file (`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.
+
+```yaml
+---
+scripts:
+  app/views/asdfs/index.html.erb:
+  - "'sha256-yktKiAsZWmc8WpOyhnmhQoDf9G2dAZvuBBC+V0LGQhg='"
+styles:
+  app/views/asdfs/index.html.erb:
+  - "'sha256-SLp6LO3rrKDJwsG9uJUxZapb4Wp2Zhj6Bu3l+d9rnAY='"
+  - "'sha256-HSGHqlRoKmHAGTAJ2Rq0piXX4CnEbOl1ArNd6ejp2TE='"
+```
+
+##### Helpers
+
+**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.
+
+```erb
+<%= 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=' ...;
+```
+
+## 3.1.2 Bug fix for regression
+
+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.
+
+## 3.1.1 Bug fix for regression
+
+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.
+
+## 3.1.0 Adding secure cookie support
+
+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:
+
+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.
+1. 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.
+1. CSP header string is produced at most once per request.
+
 ## 3.0.3
 
 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:
@@ -14,6 +300,7 @@ 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.
 

data/CODE_OF_CONDUCT.md

@@ -0,0 +1,46 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at neil.matatall@gmail.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

data/CONTRIBUTING.md

@@ -0,0 +1,41 @@
+## Contributing
+
+[fork]: https://github.com/twitter/secureheaders/fork
+[pr]: https://github.com/twitter/secureheaders/compare
+[style]: https://github.com/styleguide/ruby
+[code-of-conduct]: CODE_OF_CONDUCT.md
+
+Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.
+
+Please note that this project is released with a [Contributor Code of Conduct][code-of-conduct]. By participating in this project you agree to abide by its terms.
+
+## Submitting a pull request
+
+0. [Fork][fork] and clone the repository
+0. Configure and install the dependencies: `bundle install`
+0. Make sure the tests pass on your machine: `bundle exec rspec spec`
+0. Create a new branch: `git checkout -b my-branch-name`
+0. Make your change, add tests, and make sure the tests still pass and that no warnings are raised
+0. Push to your fork and [submit a pull request][pr]
+0. Pat your self on the back and wait for your pull request to be reviewed and merged.
+
+Here are a few things you can do that will increase the likelihood of your pull request being accepted:
+
+- Write tests.
+- Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
+- Write a [good commit message](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
+
+## Releasing
+
+0. Ensure CI is green
+0. Pull the latest code
+0. Increment the version
+0. Run `gem build secure_headers.gemspec`
+0. Bump the Gemfile and Gemfile.lock versions for an app which relies on this gem
+0. Test behavior locally, branch deploy, whatever needs to happen
+0. Run `bundle exec rake release`
+
+## Resources
+
+- [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
+- [Using Pull Requests](https://help.github.com/articles/about-pull-requests/)

data/Gemfile

@@ -1,14 +1,22 @@
+# frozen_string_literal: true
 source "https://rubygems.org"
 
 gemspec
 
 group :test do
-  gem "tins", "~> 1.6.0" # 1.7 requires ruby 2.0
+  gem "coveralls"
+  gem "json", "~> 1"
   gem "pry-nav"
-  gem "rack"
-  gem "guard-rspec", platforms: [:ruby_19, :ruby_20, :ruby_21, :ruby_22]
-  gem "rspec", ">= 3.1"
+  gem "rack", "~> 1"
+  gem "rspec"
+  gem "rubocop", "~> 0.47.0"
+  gem "rubocop-github"
+  gem "term-ansicolor", "< 1.4"
+  gem "tins", "~> 1.6.0" # 1.7 requires ruby 2.0
+end
+
+group :guard do
   gem "growl"
+  gem "guard-rspec", platforms: [:ruby_19, :ruby_20, :ruby_21, :ruby_22, :ruby_23, :ruby_24]
   gem "rb-fsevent"
-  gem "coveralls", platforms: [:ruby_19, :ruby_20, :ruby_21, :ruby_22]
 end

data/Guardfile

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 guard :rspec, cmd: "bundle exec rspec", all_on_start: true, all_after_pass: true do
   require "guard/rspec/dsl"
   dsl = Guard::RSpec::Dsl.new(self)