1

I'm trying to figure out if I completely understand CSRF security properly. Based on this OWASP cheat sheet.

In all scenarios it seems like your frontend has to have the CSRF token somewhere so that when a request is sent to the backend, it can compare both the csrf token in the cookie/session to the request. That way when an attacker tries to create a request on behalf of a logged in user, since they don't have the token in the request, it won't be validated.

This means in order for CSRF implementation you need to configure both front and backend.

Now let's say I want all the CSRF security to be done on the backend is this possible, not changing frontend? Also, if my frontend application is separated from the backend, do I still need to be worried about CSRF attacks?

Improve this question
1
  • 2
    CSRF is a browser (aka front end) related security concern, so it is not possible to secure against it exclusively from the backend.
    – Conor Mancone
    Commented Sep 28, 2020 at 18:57

1 Answer 1

Reset to default
1

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.

Improve this answer
3
  • 1
    The trouble with that has historically been lack of support in older browsers, but those may have finally aged out...
    – Conor Mancone
    Commented Sep 28, 2020 at 22:59
  • The Origin header is not necessarily sent on POST requests. That's a non-standard behavior found only in Blink- (or maybe WebKit-)based browsers. Only CORS requests - not HTML form submissions or non-CORS fetch requests - are required to send the Origin header. Assuming that if the header is absent the request must be same-origin is incorrect and insecure. Blocking requests that don't contain the Origin header may block legitimate traffic (unless all legitimate traffic is cross-origin anyhow - e.g. from app.domain.com to api.domain.com - in which case your approach can work).
    – CBHacking
    Commented Jun 29, 2022 at 5:48
  • Also, the samesite cookie flag is much looser than people think. In particular, subdomains are almost always treated as being the same site (the exceptions depend on the Public Suffix List) and the "site" of a cookie doesn't consider the port (and may or may not consider the protocol) either, so various attacks such as subdomain takeover can make CSRF possible again if you just rely on samesite, even samesite=strict.
    – CBHacking
    Commented Jun 29, 2022 at 5:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .