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 9 hours ago | parent | next [-]

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.

▲ 2 hours ago | parent | prev | next [-]

[deleted]

▲ 8n4vidtmkvmk 3 hours ago | parent | prev | next [-]

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 2 hours ago \| parent [-]
		+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

▲ nchmy 7 hours ago | parent | prev | next [-]

Can you share links to better guidance than OWASP?

▲ tptacek 3 hours ago | parent | prev [-]

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

	▲	flomo an hour ago \| parent [-]
		Completely agree. But fyi if necessary there is a bunch of dev training stuff around this, implying like "don't do an owasp or you're in trouble".