
Request for a new header: State-Of-The-Art - jewbacca
https://medium.com/@homakov/request-for-a-new-header-state-of-the-art-9a1935bbad72#.6507jfigt
======
icebraining
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.

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

~~~
icebraining
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.

~~~
csense
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.

~~~
icebraining
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](https://www.owasp.org/index.php/OWASP_Secure_Headers_Project)
(OWASP in general, though I hear the crypto stuff is weak)

[https://securityheaders.io/](https://securityheaders.io/)

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

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

[https://en.wikipedia.org/wiki/Rabbit%E2%80%93duck_illusion](https://en.wikipedia.org/wiki/Rabbit%E2%80%93duck_illusion)

------
ctcherry
Relevant XKCD, Standards: [https://xkcd.com/927/](https://xkcd.com/927/)

------
hinkley
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.

------
beaconstudios
> 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.

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

