Skip to main content
Information Security

Return to Answer

added 166 characters in body
Source Link
multithr3at3d
multithr3at3d
  • 13.2k
  • 3
  • 34
  • 45

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 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 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.

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 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 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.

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 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 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.

Source Link
multithr3at3d
multithr3at3d
  • 13.2k
  • 3
  • 34
  • 45

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 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 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.