Ory Hydra uses CSRF cookies as part of its security model, particularly for browser-based flows. The documentation and related issues indicate that Hydra sets a CSRF cookie for browser applications to protect against cross-site request forgery attacks. However, the knowledge sources do not explicitly state why Hydra does not also require a CSRF token to be sent in a header or as a form value, as is common in some other systems. In contrast, Ory Kratos (another Ory product) does require both a CSRF cookie and a CSRF token in the form body for browser flows, following the synchronizer token pattern. This is clearly documented for Kratos, where the CSRF token from the cookie must match the value submitted in the form or request body to be accepted, providing an additional layer of protection against CSRF attacks [Defenses against cross-site request forgery](https://www.ory.sh/docs/kratos/concepts/security#defenses-against-cross-site-request-forgery). For Hydra, the available documentation focuses on configuring the CSRF cookie (such as its SameSite mode, domain, and name) and troubleshooting common CSRF issues, but does not mention the use of a CSRF header or form value in the flow. This suggests that Hydra relies solely on the CSRF cookie for its CSRF protection in browser flows [Configuring cookies](https://www.ory.sh/docs/hydra/guides/cookies) [Common CSRF pitfalls](https://www.ory.sh/docs/self-hosted/hydra/debug/csrf). In summary, the knowledge sources do not provide a definitive explanation for why Hydra uses only a CSRF cookie and not a CSRF header or form value. The design choice may be based on Hydra's specific flow architecture and threat model, but this is not explicitly documented. If you need a system that uses both a CSRF cookie and a form/header value, Ory Kratos provides this pattern, but Hydra appears to use only the cookie-based approach according to the available documentation.