So you add this header. And then something new comes up. What then?

If the same header automatically adds that meaning as well, your site can break essentially randomly, unless you keep tabs on the new stuff and adapt the site to handle them - in which case, you don't really need this header, you can just add the new stuff as it comes up.

If the header is fixed in meaning ("best practices as of 03/2017"), then what value was really gained over simply copy-pasting a list of the recommended headers as of that date?

It just seems like it's either mostly useless, or too dangerous to use.

That's simple, you just add another header, State-Of-The-Art-Plus.

Then a couple years later, you add State-Of-The-Art-Plus-Plus.

Then a couple years after that...

I read it as a versioned standard. You'd have a SOTA:1, SOTA:2 etc.

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.

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.

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/

I can't tell if this is serious or satire.

It is both. Like that drawing of a duck that's also a rabbit. ;-)

https://en.wikipedia.org/wiki/Rabbit%E2%80%93duck_illusion

Relevant XKCD, Standards: https://xkcd.com/927/

Response header size notwithstanding, isn't this really a problem of app servers having really shitty default headers?

You make people turn off safety features manually and the rest of us are fine.

> Allows CORS from any domain with any headers without OPTIONS preflights.

That'd be a great way to make CSRF attacks from any domain a default setting.

And then we will have compatibility tests for browsers that implement how they read SOTA differently. Yuck