github / secure_headers

Manages application of security headers with many safe defaults
MIT License
3.16k stars 252 forks source link

Add support for Permissions-Policy header #275

Open oreoshake opened 8 years ago

oreoshake commented 8 years ago

Note: this issue used to focus on feature policy. Feature policy has been replaced with permissions-policy. While the two aren't equal, they are somewhat interchangeable for the discussion to this point.

Add support for Feature Policy. Feature policy needs to have support for highly dynamic policies just like CSP.

See Mike West's AppSec EU presentation @39:21

  • Is the header supported by any user agent? If so, which?

A prototype is in chrome (ship in Q4?)

  • What does it do?

Enables/disables features in web browsers/

  • What are the valid values for the header?

Examples:

Feature-Policy: {"disable":["geolocation"], "target":["https://example.com"]}

Feature-Policy: {"disable":["webrtc"], "target":["https://example.com"]},
        {"enable":["webrtc"], "target":["https://other.com"]}
  • Where does the specification live?

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

jacobbednarz commented 8 years ago

Looks great! Definitely keen to get on board with this one (even as a guinea pig just for chrome).

oreoshake commented 8 years ago

Abstracting out the dynamic part of how CSP is handled will help with this and https://github.com/twitter/secureheaders/issues/256 (setting two policies)

oreoshake commented 6 years ago

This is in Chrome behind a flag now, might be worth adding support.

jacobbednarz commented 6 years ago

This is getting some traction and I'm wondering if we want to take a pass at getting this into the library to at least be ready for when more browsers ship this.

oreoshake commented 6 years ago

The wonderful thing about random headers is that browsers that don’t grok them ignore them.

The terrible thing about random headers is that browsers that partially grok them behave in seemingly undefined ways.

oreoshake commented 6 years ago

We should probably file an issue in rails/rails too. I'm not sure if the syntax/values have changed and I'm too swamped to write out a more well thought out issue. We should mention that it'll need a similar API to the CSP support (dynamic policies)

jacobbednarz commented 6 years ago

sounds like a plan - i might do it in the coming days seeing how we are on rails 5 now too.

jacobbednarz commented 6 years ago

FWIW, I've raised this with Rails at https://github.com/rails/rails/pull/33439 🀞 it gets in a one less reason to have this gem maintained.

oreoshake commented 5 years ago

Now that https://github.com/rails/rails/pull/33439 has shipped this feature ahead of secure_headers, maybe it's time to officially archive this project πŸ˜„ πŸš€

reedloden commented 5 years ago

As per https://scotthelme.co.uk/security-headers-updates/, https://securityheaders.com now requires Feature-Policy support in order to get an A+. So, might still need to add support for it, as the new Rails won't be used by folks for a while.

jacobbednarz commented 5 years ago

As per https://scotthelme.co.uk/security-headers-updates/, https://securityheaders.com now requires Feature-Policy support in order to get an A+.

I disagree with some of the grading decisions here. While Feature Policy is great initiative, support and directives are still lacking by most vendors. Chrome is the by largest based on relative usage and they only have support for a fifth of the directives (including the security focused ones!). Feature Policy doesn't yet have enough adoption by vendors to deem it an acceptable mitigation tactic, yet.

So, might still need to add support for it, as the new Rails won't be used by folks for a while.

You don't really need this gem to implement the Feature Policy as you can use the config.action_dispatch.default_headers for application wide implementations or apply overrides on a per controller/component basis. Before landing this upstream in Rails, I had the 5.x implementation on our monorail and ended up reverting the lot to in favour of using default_headers as it was far more complicated than majority of use cases I could come up with. The only reason I opted for a more complicated implementation in Rails master was that CSP landed using a similar pattern and to prevent bike shedding the discussion, I followed that.

I'm +1 with @oreoshake here that majority of the complexity and functionality that secure_headers provided is available OOTB with Rails so the gem is nearing end of life.

oreoshake commented 5 years ago

feature policy support in rails 6.1 https://blog.saeloun.com/2019/10/01/rails-6-1-adds-http-feature-policy.html

cybertronprime commented 3 years ago

I am using me react app, where should I add support permission?