Open oreoshake opened 8 years ago
Looks great! Definitely keen to get on board with this one (even as a guinea pig just for chrome).
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)
This is in Chrome behind a flag now, might be worth adding support.
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.
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.
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)
sounds like a plan - i might do it in the coming days seeing how we are on rails 5 now too.
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.
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 π π
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.
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.
feature policy support in rails 6.1 https://blog.saeloun.com/2019/10/01/rails-6-1-adds-http-feature-policy.html
I am using me react app, where should I add support permission?
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
A prototype is in chrome (ship in Q4?)
Enables/disables features in web browsers/
Examples:
https://wicg.github.io/feature-policy/