[owenthejumper]

Right now the problem is what the author already mentions - the use of Sec-Fetch-Site (FYI, HTTP headers are case insensitive :) - is considered defense in depth in OWASP right now, not a primary protection.

Unfortunately OWASP rules the world. Not because it's the best way to protect your apps, but because the corporate overloads in infosec teams need to check the box with "Complies with OWASP Top 10"

[miguelgrinberg]

Hi, author here.

This was actually a mistake. If you look at the OWASP cheat sheet today you will see that Fetch Metadata is a top-level alternative to the traditional token-based protection.

I'm not sure I understand why, but the cheat sheet page was modified twice. First it entered the page with a top-level mention. Then someone slipped a revision that downgraded it to defense in depth without anyone noticing. It has now been reverted back to the original version.

Some details on what happened are in this other discussion from a couple of days ago: https://news.ycombinator.com/item?id=46347280.

[8n4vidtmkvmk]

Since when are they case sensitive? https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... says otherwise.

It's possible for a server to treat them as case sensitive, but that seems like a bad idea.

[thomascountz]

+1

HTTP/2, headers are not unique if they only differ by casing, but they must be encoded as lowercase.

   Just as in HTTP/1.x, header field names are strings of ASCII characters that are compared in a case-insensitive fashion. However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2.  A request or response containing uppercase header field names MUST be treated as malformed (Section 8.1.2.6).[1]

HTTP/1.X, headers are insensitive to casing for reasons of comparison and encoding.

   Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.[2]

So, if Sec-Fetch-Site is sensitive at all, it would be sec-fetch-site when sending via HTTP/2 and you're responsive for encoding/decoding.

[1]: https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2

[2]: https://datatracker.ietf.org/doc/html/rfc2616#section-4.2

[thatwasunusual]

>> FYI, HTTP headers are case insensitive

> Since when are they case sensitive?

[...]

[jonway]

My primitive instincts lead me to believe that sometimes they end up being Case-Sensitive and Sometimes NoT! (depending on implementation)

[nchmy]

Can you share links to better guidance than OWASP?

[tptacek]

The OWASP Top 10 is a list of vulnerabilities, not a checklist of things you have to actually "do".

[scott_w]

While you’re correct, corporate security teams demand suppliers “comply with OWASP,” despite this being a nonsensical statement to anyone who’d read the website.

Unfortunately, the customer purchasing your product doesn’t know this and (naturally) trusts their own internal experts over you. Especially given all their other suppliers are more than happy to state they’re certified!

[ozim]

If you look from perspective of vulnerability assessment, it kind of is.

[flomo]

Completely agree. But fyi there is a bunch of dev training stuff around this, implying like "don't do an owasp or you're in trouble".