Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Adds support for configuring HTTP Feature Policy #33439
A HTTP feature policy is Yet Another HTTP header for instructing the
WICG specification: https://wicg.github.io/feature-policy/
The end result is a HTTP header that looks like the following:
This will prevent the browser from using geolocation and only allow
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
This change doesn't introduce support for defining a feature policy on
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.
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 ```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 #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. : https://github.com/WICG/feature-policy/blob/master/features.md : https://www.chromestatus.com/feature/5694225681219584 : https://bugzilla.mozilla.org/show_bug.cgi?id=1390801 : https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy : https://developers.google.com/web/updates/2018/06/feature-policy
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.
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.
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.
Re. draft spec stability: w3c/webappsec-feature-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.