Re: Very arbitrary definition of "secure" headers
Not really, AC. Strict-Transport-Security doesn't rely on browser support to be useful. Every website should be served up over HTTPS, and every website should also implement the HSTS header, because for those browsers that support it - and bear in mind MS are working very hard to kill off IE <11 - it means there's never an HTTP request that needs redirecting after the first ever request to the site. There are also preload lists implemented by browsers.
Content-Security-Policy has one very simple setting - upgrade-insecure-requests - which you can set to ensure that none of the resources linked from within your page are ever served over HTTP. I don't understand how anyone could argue against that being a good idea. You can also set all sorts of other restrictions, which are great if implemented properly. At least having the header served up shows that a non-zero amount of thought has gone into external resources.
Public-Key-Pins is something everyone should just do. Serve up two pins - one relates to your private key, and the other relates to a backup private key. If you change your certificate, so what? It's the same private key, and hence the same public key. You serve up the backup pin in case your private key is compromised. It's a commonly held myth that the pin is for the certificate. It isn't. It's a hash on the public key. Not the same thing as a certificate.
Why wouldn't you set X-Frame-Options? What more efficient options are there for stopping your site being framed as phish bait?
Why wouldn't you set X-XSS-Protection? Leaving it unset allows IE to bypass its own filters for backward compatibility purposes. It's madness to suggest this means nothing. For IE, it means everything, and IE remains the number one target, even if it's no longer the most popular browser.
Why wouldn't you set X-Content-Type-Options? Are you suggesting it's OK not to set it if you couldn't be bothered declaring content types correctly? Or if you have someone who might use your site with an older browser? Screw those guys using newer browsers, because there's someone using an older browser which will ignore this header, I'm going to leave an XSS hole open for them.
Your caching safety headers will leak information to disk. They don't cut it. You should have said:
For HTTP 1.1:
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0
For HTTP 1.0:
Pragma: no-cache
Expires: 0
An interesting comment, but in no measure a demonstration of understanding of web application security...