Yes, one method of ensuring CSRF protection is to check the Origin and Referrer headers to see whether they match the expected origin, as these headers [cannot be overwritten][1] by any frontend code. However, the origin header is only sent on POST or CORS requests, and the browser implementations of these headers have historically not been consistent; e.g. possibly allowing JavaScript to spoof one or more of the headers (modern browsers _should_ behave correctly, although I cannot speak for the future spec or implementation).

This protection only requires implementing a server-side check on every POST request. It is important to deny the request if the sent origin doesn't match, or if none was sent at all.

The [OWASP CSRF Cheat Sheet][2] includes some reasons for why you may not want to use this method exclusively. However, if you face none of those restrictions, I personally feel that this method is okay to use in lieu of a more complex method.

Also depending on browser support is the "SameSite: strict" cookie option. This prevents cookies from being sent at all from a 3rd party site, also mitigating CSRF.


  [1]: https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name
  [2]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#identifying-the-target-origin