Explore Sec-Fetch Headers as a Core-Supported CSRF Mitigation Mechanism

[nickchomey]

Sec-Fetch headers (1) are a modern browser standard designed explicitly to make CSRF protection simpler and less error-prone. They are recommended by OWASP (2) (with a fallback to Origin headers for the small percentage of devices that have not yet updated to recent browser versions) (3), and are increasingly being adopted or considered by major frameworks and platforms as a primary CSRF mitigation mechanism (4).

WordPress currently relies on nonces as its primary CSRF mitigation mechanism. While effective, nonces are not always consistently applied across plugins and themes, and their per-request nature can complicate caching and scalability, particularly for front-end interactive features.

I’d like to propose a discussion around introducing Sec-Fetch header validation as a core-supported CSRF mitigation mechanism, either as a defense-in-depth measure alongside existing nonce checks, or as an optional alternative in narrowly scoped contexts where request metadata provides sufficient CSRF guarantees (e.g., REST endpoints, admin-AJAX, or certain front-end interactions).

I’m aware that WordPress nonces may serve additional roles beyond CSRF mitigation, such as request intent signaling or accidental invocation protection, and this proposal does not suggest removing or deprecating nonces, nor does it propose changes to capability checks, authentication, or authorization logic.

My hope is that this ticket can serve as a place to explore how Sec-Fetch headers might fit into WordPress’s architecture in a way that improves security, developer ergonomics, and scalability, while preserving existing behavior.

### References

(1) ​MDN: Sec-Fetch-Site

(2) ​OWASP CSRF Prevention Cheat Sheet

(3) ​Can I use: Sec-Fetch-Site browser coverage

(4) ​Go standard library (Cross-Origin Protection, released in v1.25)
​Rails `protect_from_forgery` (planned for v8.2)
​Django (Fetch Metadata discussion)

[nickchomey]

Apologies, there was a formatting error in the references above. Too late to edit it.

(1) ​MDN: Sec-Fetch-Site
(2) ​OWASP CSRF Prevention Cheat Sheet
(3) ​Can I use: Sec-Fetch-Site browser coverage
(4) ​Go standard library (Cross-Origin Protection, released in v1.25)
​Rails `protect_from_forgery` (planned for v8.2)
​Django (Fetch Metadata discussion)