undefined | Better HN

0 pointsicebraining9y ago0 comments

Then it falls under my second point: why add more complexity to browsers, when you can just copy-paste this year's recommended header list? Unless the idea is to do away with the other headers, but that seems overly restrictive - in our case, we can't implement HSTS, for example.

0 comments

2 comments · 1 top-level

csense9y ago· 1 in thread

My modern frontend experience is pretty limited, but AFAICT there is no "this year's recommended header list." Rather, these issues are presented to developers as a bunch of independent problems, each one of which you have to individually hear about, research and understand in depth before you can figure out what you actually need to do to make your application secure.

If the website works from a user perspective, and it's not being actively attacked in a way that leaves obvious signs in normal operations monitoring, then a lot of IT orgs simply won't have the mandate or the budget to go Googling to find out the very latest recommended HTTP headers.

icebrainingOP9y ago

But to create this header, someone would have to compile that list, so that browsers could know how they should interpret it. So you can just publish it and allow developers to receive updates.

By the way, there are already such lists and tools:

https://www.owasp.org/index.php/OWASP_Secure_Headers_Project (OWASP in general, though I hear the crypto stuff is weak)

https://securityheaders.io/

j / k navigate · click thread line to collapse