Comments (6)
I think I've mentioned this before: if we are talking about genuine problems, then yes, exceptions should be thrown, so that developers notice and can deal with them. Headers will get lost, but so be it, you will likely have larger problems at that point.
For advice, you are right, probably shouldn't use the exception mechanism for that.
from secureheaders.
@jens1o Were there any other situations you had in mind where SecureHeaders issues a warning but it maybe should be an exception?
I think I'm probably going to look into being able to mute any warning that SecureHeaders issues. You can already do this for some things, but I think it would be beneficial to have an "I accept this specific risk" option for everything. This would let you turn off a specific warning without bulk disabling all errors (and consequently being blind to all advisories). The code disabling that specific warning would also serve as a reminder in future to a reader as-to whether it is still an appropriate risk. Not sure if this would perhaps better address the situation here?
from secureheaders.
In that case I think I'll close this for now in favour of the changes described (I'll track these in #71), do feel free to re-open if you spot something at some point though :)
I think I may try and aim towards a way at receiving these warnings and notices in ways other than just page output too – so if desired you could log them separately for example.
from secureheaders.
Just to replicate some of the referenced discussion in this issue so this issue is self-contained:
This is definitely something worth thinking about for 3.0
, would be a BC break to start doing it by default now (at least on current functionality). Perhaps there is room for refactoring things into exceptions and have SecureHeaders convert them to errors by default, but have a config to let the exceptions go uncaught and be exposed to the user.
Things to think about with errors v.s. exceptions:
- Exceptions will generally cause headers not to reach the adapter, and so won't be sent. i.e.
- Is no CSP better than suboptimal CSP? (bearing in mind loss of reporting header which might be stricter too).
- Is not sending a suboptimal CSP better than HSTS, Referrer-Policy, cookie upgrades, ...?
- It we throw exceptions, they should be genuine problems. That means not throwing an exception for advice: we cannot use exceptions to tell the dev they they should use something (learning opportunity). Learning opportunities would have to be disposed of if we converted all errors as used currently to exceptions.
So I think it best to discuss decoupling some things that should be exceptions, from things that are learning opportunities. I don't want to throw an exception every time SecureHeaders can advise to do something (in-fact because these advisements are not exceptions, new advisements can be added in a backwards compatible manner – which is good for pushing current best standards. This is not achievable with things that will cause a fatal error).
from secureheaders.
No contest to any of that.
Speaking to the original issue raised RE #60, I consider the message given there to be advice. It's strictly opportunistic injection (see #1). We want to encourage the user to adopt nonces/hashes in favour of the whitelist (strict dynamic tells CSP3 browsers to kill the whitelist). If they can't do that then we don't inject strict dynamic because killing the whitelist without any nonces/hashes will likely break their application (not because it's wrong on a policy writing level).
Further to the discussion here, are there any errors that come to mind that we currently issue, that probably should be exceptions?
from secureheaders.
Hi there,
tbh, I do not know the codebase anymore. So I do not know exactly where I was complaining, and I do not have time to dig into this atm. :/
But I do like your approach in general :)
from secureheaders.
Related Issues (20)
- 2.0 Planned Changes HOT 19
- 2.0: removeCookies() has no effect HOT 4
- Proposal: Move most documentation to PhpDoc blocks HOT 14
- Discuss finally releasing 2.0 HOT 2
- Increase Test Coverage
- [2.0] Readme is out of date
- `strict-origin-when-cross-origin` doesn't seem to be supported by Chrome HOT 4
- allow method chaining HOT 13
- Report missing CSP directives
- `'strict-dynamic'` isn't injected into CSP Report-Only
- More intuitive config
- Drop PHP 5.x HOT 8
- Auto protected session cookie HOT 5
- Conditional Intent to Deprecate and Remove: Public Key Pinning
- Increase test coverage
- Add hashes and nonces as friendly directive HOT 2
- Option to manually disable warnings HOT 4
- Don't warn for 'unsafe-inline' if hash or nonce present in applicable directive
- Rethink cookie upgrades HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from secureheaders.