Adds support for configuring HTTP Feature Policy #33439

jacobbednarz · 2018-07-26T01:45:10Z

A HTTP feature policy is Yet Another HTTP header for instructing the
browser about which features the application intends to make use of and
to lock down access to others. This is a new security mechanism that
ensures that should an application become compromised or a third party
attempts an unexpected action, the browser will override it and maintain
the intended UX.

WICG specification: https://wicg.github.io/feature-policy/

The end result is a HTTP header that looks like the following:

Feature-Policy: geolocation 'none'; autoplay https://example.com

This will prevent the browser from using geolocation and only allow
autoplay on https://example.com. Full feature list can be found over
in the WICG repository.

As of today Chrome and Safari have public support for this
functionality with Firefox working on support and Edge still pending
acceptance of the suggestion.

Examples

Using an initializer

# config/initializers/feature_policy.rb
Rails.application.config.feature_policy do |f|
  f.geolocation :none
  f.camera      :none
  f.payment     "https://secure.example.com"
  f.fullscreen  :self
end

In a controller

class SampleController < ApplicationController
  def index
    feature_policy do |f|
      f.geolocation "https://example.com"
    end
  end
end

Some of you might realise that the HTTP feature policy looks pretty
close to that of a Content Security Policy; and you're right. So much so
that I used the Content Security Policy DSL from #31162 as the starting
point for this change.

This change doesn't introduce support for defining a feature policy on
an iframe and this has been intentionally done to split the HTTP header
and the HTML element (iframe) support. If this is successful, I'll
look to add that on it's own.

Full documentation on HTTP feature policies can be found at
https://wicg.github.io/feature-policy/. Google have also published a
great in-depth write up of this functionality.

rails-bot · 2018-07-26T01:45:12Z

Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @georgeclaghorn (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review.

Please see the contribution instructions for more information.

jacobbednarz · 2018-07-26T01:47:53Z

cc @pixeltrix as you implemented the CSP DSL and this is along the same lines.

A HTTP feature policy is Yet Another HTTP header for instructing the browser about which features the application intends to make use of and to lock down access to others. This is a new security mechanism that ensures that should an application become compromised or a third party attempts an unexpected action, the browser will override it and maintain the intended UX. WICG specification: https://wicg.github.io/feature-policy/ The end result is a HTTP header that looks like the following: ``` Feature-Policy: geolocation 'none'; autoplay https://example.com ``` This will prevent the browser from using geolocation and only allow autoplay on `https://example.com`. Full feature list can be found over in the WICG repository[1]. As of today Chrome and Safari have public support[2] for this functionality with Firefox working on support[3] and Edge still pending acceptance of the suggestion[4]. #### Examples Using an initializer ```rb # config/initializers/feature_policy.rb Rails.application.config.feature_policy do |f| f.geolocation :none f.camera :none f.payment "https://secure.example.com" f.fullscreen :self end ``` In a controller ```rb class SampleController < ApplicationController def index feature_policy do |f| f.geolocation "https://example.com" end end end ``` Some of you might realise that the HTTP feature policy looks pretty close to that of a Content Security Policy; and you're right. So much so that I used the Content Security Policy DSL from rails#31162 as the starting point for this change. This change *doesn't* introduce support for defining a feature policy on an iframe and this has been intentionally done to split the HTTP header and the HTML element (`iframe`) support. If this is successful, I'll look to add that on it's own. Full documentation on HTTP feature policies can be found at https://wicg.github.io/feature-policy/. Google have also published[5] a great in-depth write up of this functionality. [1]: https://github.com/WICG/feature-policy/blob/master/features.md [2]: https://www.chromestatus.com/feature/5694225681219584 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801 [4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy [5]: https://developers.google.com/web/updates/2018/06/feature-policy

jacobbednarz · 2018-07-26T03:50:49Z

actionpack/test/dispatch/feature_policy_test.rb

+    end
+
+    feature_policy only: :sample_controller do |f|
+      f.gyroscope nil


I'm not sure how I feel about this API. The idea is that you define a global policy you need to be explicit about overriding it with nil to remove it. Thoughts?

rafaelfranca · 2018-09-13T19:59:54Z

This seems to be a very unstable API that may change any time. I don't think it is mature enough to be included in a framework just yet.

jeremy · 2018-09-13T22:42:39Z

Cool! Makes me want an explicitly-experimental API status so app developers can track this as it's developed, but the clear expectation that it may change to track upstream.

jacobbednarz · 2018-09-13T22:52:34Z

I can definitely see your concerns here @rafaelfranca and they are warranted as many of these new browser security features can go through multiple iterations before becoming usable by more than a single browser (I'm looking at your content security policy!).

I really like @jeremy's idea of explicitly calling this out as potentially experimental due to the browser implementations not all solidified yet. I think that will give us a nice middle ground of adding security for those that do want to use this feature while still maintaining some sensibility in the framework itself.

rafaelfranca · 2018-09-13T23:39:55Z

I'm ok with that. My worry is that if they rename a configuration it would require a released of the framework to rename that configuration. Having this is a gem would give more flexibility. I'm happy to keep an official Rails gem for this with the promise to integrate to the framework as soon the API is stable enough.

jacobbednarz · 2018-09-14T21:05:33Z

Rather timely occurrence, this morning Mozilla has announced they will be shipping this to nightly - https://groups.google.com/d/msg/mozilla.dev.platform/w3elPpZlqIE/ZA5cuKOMCAAJ

That just leaves Edge without support (for now) from the majority of browsers.

jeremy · 2018-09-14T21:23:44Z

Re. draft spec stability: w3c/webappsec-permissions-policy#218 (comment)

I'm all for pitching larger additions like this via gems too. However, I think this particular spec, like CSP before it, is important enough to bake in as a default for new Rails 6 apps. And during prerelease is the prime time to iterate on the new-app and upgrade experience.

rafaelfranca · 2018-09-20T19:37:28Z

Sounds good to me them. Let's move to document this PR so we can merge before the pre release.

jacobbednarz · 2018-09-20T23:02:41Z

@rafaelfranca Sure thing! Would you like the documentation in this PR or would you link a separate one for that?

jacobbednarz · 2019-03-25T01:34:48Z

@jeremy @rafaelfranca could either of you point me towards the documentation that you're expecting here and we can get this one over the line?

jacobbednarz · 2019-07-09T22:58:46Z

I've gone ahead and updated this to the latest master as well as adding a CHANGELOG entry for the new DSL. Sing out if you want more documentation in other forms.

jeremy

🙏🏼

jeremy · 2019-07-10T06:14:24Z

actionpack/lib/action_controller/metal/feature_policy.rb

+# frozen_string_literal: true
+
+module ActionController #:nodoc:
+  module FeaturePolicy


Good spot for docs here (

rails/actionpack/lib/action_controller/metal/content_security_policy.rb

Line 5 in 6e40b13

# TODO: Documentation

notwithstanding 😅). Using the changelog entry verbatim could work well!

Thanks for the pointer @jeremy! I wasn't sure if the intention was for code documentation or something like the Guide documentation. I'll get something added here as a start.

Addressed this in 88fb316.

jacobbednarz · 2019-07-10T06:35:26Z

Let me know when/if we're ready here and I'll squash this into a single commit before merging it. (Unless whoever merges is happy squashing-when-merging using the GitHub UI and just take the initial commit)

y-yagi · 2019-07-13T23:46:39Z

railties/lib/rails/generators/rails/app/templates/config/initializers/feature_policy.rb.tt

+#   f.microphone  :none
+#   f.usb         :none
+#   f.fullscreen  :self
+#   f.payment     :self, "https://secure-example.com"


Unlike example.com, secure-example.com is a domain that can be used normally. It should not be used as an example.

Good catch. While this is only an example for configuration, we should definitely avoid using real world domains and instead restrict to using using the reserved domains. I'll open a PR to address.

`speaker`, `vibrate`, and `vr` were [listed as policy-controlled features][1] around the time when rails#33439 was first written (2018-07-25). However, `vibrate` was removed in w3c/webappsec-permissions-policy@b7271ac, `vr` was changed to `xr` in w3c/webappsec-permissions-policy@bec5ce6, and `speaker` was removed in w3c/webappsec-permissions-policy@18707d3. (And `xr` was later changed to `xr-spatial-tracking`, and still only has [experimental support][2].) Therefore, this commit deprecates these permissions policy directives. [1]: https://github.com/w3c/webappsec-permissions-policy/blob/6d8bbbe738368c317d280bb866c66cedaef3391c/features.md#policy-controlled-features [2]: https://github.com/w3c/webappsec-permissions-policy/blob/432a1532c943a079351eecbc445ae4c6ed9b949c/features.md#standardized-features

rails-bot assigned georgeclaghorn Jul 26, 2018

jacobbednarz mentioned this pull request Jul 26, 2018

Add support for Permissions-Policy header github/secure_headers#275

Open

jacobbednarz force-pushed the add-feature-policy branch from 5097856 to 68d216a Compare July 26, 2018 01:57

jacobbednarz force-pushed the add-feature-policy branch from 68d216a to de928c2 Compare July 26, 2018 03:31

jacobbednarz commented Jul 26, 2018

View reviewed changes

jeremy requested a review from pixeltrix September 13, 2018 22:42

gmcgibbon added actionpack railties labels Sep 28, 2018

jacobbednarz added 2 commits July 10, 2019 08:48

Merge in upstream/master

af05f6c

Add CHANGELOG entry for HTTP feature policy

f81db9f

jeremy approved these changes Jul 10, 2019

View reviewed changes

Add code level documentation for functionality

88fb316

Indentation and whitespace fixes

cd85d93

jacobbednarz force-pushed the add-feature-policy branch from a47d6a1 to cd85d93 Compare July 10, 2019 22:02

jeremy merged commit bf19b87 into rails:master Jul 10, 2019

jacobbednarz deleted the add-feature-policy branch July 10, 2019 22:41

y-yagi reviewed Jul 13, 2019

View reviewed changes

jacobbednarz mentioned this pull request Jul 14, 2019

Use reserved domain for example configuration #36679

Merged

jonathanhefner mentioned this pull request Oct 5, 2022

Deprecate obsolete permissions policy directives #46199

Merged

jonathanhefner mentioned this pull request Oct 5, 2022

Update permissions policy list #45427

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adds support for configuring HTTP Feature Policy #33439

Adds support for configuring HTTP Feature Policy #33439

jacobbednarz commented Jul 26, 2018

rails-bot commented Jul 26, 2018

jacobbednarz commented Jul 26, 2018

jacobbednarz Jul 26, 2018

rafaelfranca commented Sep 13, 2018

jeremy commented Sep 13, 2018

jacobbednarz commented Sep 13, 2018

rafaelfranca commented Sep 13, 2018

jacobbednarz commented Sep 14, 2018

jeremy commented Sep 14, 2018

rafaelfranca commented Sep 20, 2018

jacobbednarz commented Sep 20, 2018

jacobbednarz commented Mar 25, 2019

jacobbednarz commented Jul 9, 2019

jeremy left a comment

jeremy Jul 10, 2019

jacobbednarz Jul 10, 2019

jacobbednarz Jul 10, 2019

jacobbednarz commented Jul 10, 2019

y-yagi Jul 13, 2019

jacobbednarz Jul 14, 2019

Adds support for configuring HTTP Feature Policy #33439

Adds support for configuring HTTP Feature Policy #33439

Conversation

jacobbednarz commented Jul 26, 2018

Examples

rails-bot commented Jul 26, 2018

jacobbednarz commented Jul 26, 2018

jacobbednarz Jul 26, 2018

Choose a reason for hiding this comment

rafaelfranca commented Sep 13, 2018

jeremy commented Sep 13, 2018

jacobbednarz commented Sep 13, 2018

rafaelfranca commented Sep 13, 2018

jacobbednarz commented Sep 14, 2018

jeremy commented Sep 14, 2018

rafaelfranca commented Sep 20, 2018

jacobbednarz commented Sep 20, 2018

jacobbednarz commented Mar 25, 2019

jacobbednarz commented Jul 9, 2019

jeremy left a comment

Choose a reason for hiding this comment

jeremy Jul 10, 2019

Choose a reason for hiding this comment

jacobbednarz Jul 10, 2019

Choose a reason for hiding this comment

jacobbednarz Jul 10, 2019

Choose a reason for hiding this comment

jacobbednarz commented Jul 10, 2019

y-yagi Jul 13, 2019

Choose a reason for hiding this comment

jacobbednarz Jul 14, 2019

Choose a reason for hiding this comment