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"
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.
It's possible for a server to treat them as case sensitive, but that seems like a bad idea.
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]
Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.[2]
[1]: https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2
[2]: https://datatracker.ietf.org/doc/html/rfc2616#section-4.2
> Since when are they case sensitive?
[...]
When I originally read it hours ago, I also read it as "...HTTP headers are case sensitive," (emphasis mine).
That said, there is one caveat regarding case sensitivity for headers encoded for HTTP/2.
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!