Perfectly on time, two minutes before midnight I made it to publish a new article. Today it's about CSP and how you can use them to prevent unexpected/unwanted leaks of user data.
https://shivering-isles.com/self-isolate-your-website
Maybe not my greatest piece, but it's in the spirit on the situation and therefore 🤷 Enjoy! 
Some CSP design guidelines here too
https://webcookies.org/articles/11/typical-content-security-policy-mistakes-and-omissions
There's also CSP checker https://webcookies.org/cookies/shivering-isles.com/30386338?531471#csp
@kravietz To be honest, I wouldn't recommend this scanner. First of all, it recommends a bunch of things, that don't make any sense. Like SRI for resources from the same origin, recommending upgraded requests for a website that enforces HSTS, recommending `'strict-dynamic'` when no third-party requests are made, …
All that in combination with ads for their own service. It leaves a bit of a bad taste.
What do you mean by "ads for their own service"?
P.S. I'm the one developing this scanner so happy to accept any criticism!
I disagree here.
It's a simple service admin maturity metric. Lack of version details doesn't guarantee they're using up-to-date version, but in 99% cases exposing detailed version in the header is equivalent to a big banner "hey come and hack me because I have not touched any server hardening guidelines".
The remaining 1% is reserved for honeypots...
@kravietz Unless, you actively monitor all your endpoint exactly for those headers in order to make sure that everything is up-to-date in production.
Of course one does also monitor the machines itself, but I'm a big fan of end-to-end validation and what really matters is what is accessible for a user. Therefore I actually prefer version numbers being provided by the software. (Of course, it also forces you to take care.)
For practical operational security you definitely don't want to rely on HTTP headers because it's just the outer layer. Behind the Nginx you can have a whole bunch of other reverse-proxies, caches and microservices that can be vulnerable too.
You want to look at operating system package versions for things like Nginx and at all the dependencies of your application stack, such as Python packages in my case.
@kravietz As I said, I actually want to see both. And of course, that's an architecture dependent decision, but at least in my use-case it's perfectly fine.
You're right about CSP and SRI, this is due to the fact how rules are implemented currently and is on my TODO list.
And regarding ads for my services... yes, the service is available 100% for free and the infrastructure only costs 200 GBP/per month not counting my work, so I'm definitely not going to hide the fact that I'm also available for hire.
@kravietz Not saying you have to or should. I'm just saying that it's something I'm simply reluctant to recommend to people.
@kravietz
> "The header exposes web server version details. These server no purpose apart from making life of security auditors and hackers easier, leading them straight to exploits for this particular version of product. WebCookies.org does offer security design and penetration testing services so we can help!"
It's kind of the point of the server header to make it easy to detect versions. Hiding it is just security by obscurity and makes it harder to inform people about possible problems.