Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Permissions-Policy header #275

Open
oreoshake opened this issue Jul 20, 2016 · 13 comments
Open

Add support for Permissions-Policy header #275

oreoshake opened this issue Jul 20, 2016 · 13 comments

Comments

@oreoshake
Copy link
Contributor

oreoshake commented Jul 20, 2016

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
Copy link
Contributor

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

@oreoshake
Copy link
Contributor Author

Abstracting out the dynamic part of how CSP is handled will help with this and #256 (setting two policies)

@oreoshake
Copy link
Contributor Author

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

@jacobbednarz
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

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

@jacobbednarz
Copy link
Contributor

FWIW, I've raised this with Rails at rails/rails#33439 🤞 it gets in a one less reason to have this gem maintained.

@oreoshake
Copy link
Contributor Author

Now that rails/rails#33439 has shipped this feature ahead of secure_headers, maybe it's time to officially archive this project 😄 🚀

@reedloden
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

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

@oreoshake oreoshake changed the title Add support for "Feature Policy" header Add support for Permissions-Policy header Jan 17, 2021
@rajrohit10
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants