Secure Headers for PHP
aidanwoods.com
aidanwoods.com
In my opinion [1][2][3], it's fairly clear that C-S-P isn't a fire-and-forget header (unlike some other Security Headers) and that its generation needs to take into account rules that can be set up ahead of time and the context of the resource in question. The OWASP wiki page itself recommends this, but as far as I know, no web framework implements this.
If you know otherwise, let me know. This may be the first.
[1] https://news.ycombinator.com/item?id=12584356#12584733 [2] https://news.ycombinator.com/item?id=12408328#12408680 [3] https://news.ycombinator.com/item?id=13055470#13057260
I'd recommend manually writing the list of sources for the page type. There isn't really a safe way to just scan the page for (safe) resources unfortunately (how could you tell which resources were meant to be there?)
Point of the (CSP) part of this class is to let you break down your CSP into distinct components and then combine them together.
E.g. You need to embed a tweet – that twitter embed code will require you to add script, style, and image sources to your CSP. You could file them all quite nicely in the CSP array format, and call that variable `$twitterCSP`.
If twitter changes things in the future RE the required sources, you now know what to amend. If you decide you no longer want tweets on your page, you can get rid of unnecessary sources by deleting just `$twitterCSP` from your code – instead of leaving in sources you don't need, or having to trudge through the entire CSP string trying to figure out which sources you added to make twitter work.
Goal is source management, not auto generating the list.
Take said, this is still far better than not having a CSP or having a static one, so it's an admirable project regardless.
This makes it much easier to integrate some stuff.
As far as using the class to do it goes, there are other benefits other than just CSP management: auto cookie upgrades and error messages about poor configuration to name a few.
By specifying paths more explicitly, I whitelist less of the domain (and consequently reduce the chances that I'll whitelist something this is user controllable in the domain). I'll usually try to allow down to specific files in CSP if I can.
Hosting font awesome myself costs me money, pointing to cloudflare is free
Edit: check out my site vs. a few others using Google's CSP evaluator – you'll probably find a lot with known CSP bypasses due to their whitelisting.
Someones already raised the issue, and I'm working on it!
I wouldn't be surprised if PHP is first, but Ruby, Python, and Javascript BOTH under 1.0%? Seems highly doubtful.
That leads me to believe that this report must be generated off of websites that actually self report language. I know PHP does by default in most distros with an X-Powered-By header, but it's not clear to me what if any other languages do that by default.
For something like CSP, it becomes very difficult to maintain a list of sources very quickly. Also, for parts of CSP like nonces too – from a usability perspective, it's a lot easier to pass a nonce around in the application layer, as opposed to generating it at the Apache/Nginx level, and then trying to insert it into the HTML as the page goes out.
Goal here is to make things like CSP easier to use. Integrating security headers into a language devs are already familiar with achieves that.
Disclaimer: I wrote the post and the PHP class.
Seriously, though, for headers like CSP, where the value is dependent on application logic (in this case, which domains the served document will need to access), it entirely makes sense to set the header in your application. The same applies to caching headers. Your application is the one that knows what the ETag of the document is, not your webserver.