[wp-trac] [WordPress Trac] #64481: Explore Sec-Fetch Headers as a Core-Supported CSRF Mitigation Mechanism

[WordPress Trac]

#64481: Explore Sec-Fetch Headers as a Core-Supported CSRF Mitigation Mechanism
-------------------------+-----------------------------
 Reporter:  nickchomey   |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Security     |    Version:
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+-----------------------------
 Sec-Fetch headers [#ref1 (1)] are a modern browser standard designed
 explicitly to make CSRF protection simpler and less error-prone. They are
 recommended by OWASP [#ref2 (2)] (with a fallback to Origin headers for
 the small percentage of devices that have not yet updated to recent
 browser versions) [#ref3 (3)], and are increasingly being adopted or
 considered by major frameworks and platforms as a primary CSRF mitigation
 mechanism [#ref4 (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

 [=#ref1]
 (1) [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-
 Site: MDN: Sec-Fetch-Site]

 [=#ref2]
 (2) [https://cheatsheetseries.owasp.org/cheatsheets/Cross-
 Site_Request_Forgery_Prevention_Cheat_Sheet.html#fetch-metadata-headers:
 OWASP CSRF Prevention Cheat Sheet]

 [=#ref3]
 (3) [https://caniuse.com/mdn-http_headers_sec-fetch-site: Can I use: Sec-
 Fetch-Site browser coverage]

 [=#ref4]
 (4) [https://github.com/golang/go/issues/73626: Go standard library
 (Cross-Origin Protection, released in v1.25)]
 [https://github.com/rails/rails/pull/56350: Rails `protect_from_forgery`
 (planned for v8.2)]
 [https://github.com/django/new-features/issues/98: Django (Fetch Metadata
 discussion)]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64481>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform