A new security header: Feature Policy

We have a new Security Header!! Feature Policy will allow a site to enable or disable certain browser features and APIs in the interest of better security and privacy. Let's take a look!


Feature Policy

Feature Policy is being created to allow site owners to enable and disable certain web platform features on their own pages and those they embed. Being able to restrict the features your site can use is really nice but being able to restrict features that sites you embed can use is an even better protection to have.


HTTP Response Header

Delivering a Feature Policy via HTTP response header is just as simple as issuing the other various security headers we have available to us. You simply need to decide the restrictions you'd like to place on your page and build the policy to return. Here is a simple example:


Feature-Policy: vibrate 'self'; usermedia *; sync-xhr 'self' https://example.com

In the above example by specifying vibrate and allowing it for self the feature is disabled for all origins except our own. The sync-xhr feature is allowed by the current origin and https://example.com and usermedia is allowed by all origins. If you've had experience with Content Security Policy then this should be fairly familiar. The full list of features that can be restricted isn't final yet but here are a few things you could restrict:


  • geolocation
  • midi
  • notifications
  • push
  • sync-xhr
  • microphone
  • camera
  • magnetometer
  • gyroscope
  • speaker
  • vibrate
  • fullscreen
  • payment (PaymentRequest)

This list can and will change so keep an eye on the documents linked at the bottom of the page for updates.


Controlling Origins

Controlling which origins can use which features can be done with the following values:


  • *
  • 'self'
  • 'none'
  • <origin(s)>

Let's break those down and look at exactly what each one will allow.


*
This will allow the current page to use the feature and any nested browsing contexts inside it like iframes.


'self'
This will allow the current page to use the feature and any nested browsing contexts like iframes only if they are on the same-origin, so for example if you frame your own site on your page.


'none'
This feature will be disabled for the current page and any nested browsing contexts like iframes.


<origin(s)>
Only the specified origins will be allowed to use this feature. For exmple https://example.com or https://example.net https://example.org.


Restricting iframes

Delivering a policy as a HTTP response header applies it to the page and embedded browsing contexts within it. You may wish to have a different policy applied to each of these so you can enable features on specific iframes.


<iframe src="https://example.com" allow="vibrate">

One thing to note is that if a parent disables a feature then it can be enabled again on any child. Thus, if we disable vibrate in our HTTP response header we can enable it only for a specific iframe. To demonstrate, if we issue the following header on our page it would result in the iframe on our page not having the vibrate feature but we can enable it specifically.


Feature-Policy: vibrate 'none'

<iframe src="https://example.com" allow="vibrate">

Of course, the other way we could specify this policy is to allow example.com access to vibrate in the response header, but that would grant it to all child contexts loaded from that origin.


Feature-Policy: vibrate 'self' example.com

<iframe src="https://example.com">

Feature Policy provides a fair amount of flexibility in this regard so it should be easy enough to deploy in a manner that affords real protection.


Support

Even though it is still early days we already have support in Chrome and Safari. I'd like to start getting visibility of these new features out there so we can start increasing adoption and as browser support follows, we will only get more and more benefit from deploying them.


Security Headers

To further the exposure of the header I will be adding detection to Security Headers. The header will not have a weight to impact the grade but it will be flagged as required. I can start to track utilisation and make people aware of its existence to drive adoption!


security-headers-feature-policy


FP RFC: https://wicg.github.io/feature-policy/

List of FP features: https://github.com/WICG/feature-policy/blob/master/features.md

Chromium Source list of features supported: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/feature_policy/feature_policy.cc?l=138&rcl=ab90b51c5b60de15054a32b0bd18e4839536a1c9

Chrome Platform Status: https://www.chromestatus.com/features#component%3A Blink>FeaturePolicy

Feature Policy Explainer: https://docs.google.com/document/d/1k0Ua-ZWlM_PsFCFdLMa8kaVTo32PeNZ4G7FFHqpFx4E/edit