While I can see some of the overheads of CSRF protection (generation of token, validation of token, extra work to implement), I can't see any reason why you would ever not want it.

Is there ever a case where CSRF protection is something that should NOT be used? I'm not talking about cases where it's unnecessary, such as actions with no side effects, but cases where its use is actually a bad idea.

  • 1
    When you create an application for CSRF demonstration?
    – Noir
    Jul 29, 2016 at 13:53
  • Form posts originating from third-party domains
    – paj28
    Jul 30, 2016 at 7:43

2 Answers 2


Actually, there may be a use case, but it is a little contrived and depends on how the CSRF token is generated.

In many cases, the CSRF token is just a random token which is tied to the session and is not related to any level of authentication. When the client requests a page containing a web form, the form has the token embedded in it as a hidden field. When the client posts the form data, the server verifies the token is the same as the one it sent and can be fairly confident the response is from the same client it sent the form to. All good.

However, this work flow is less convenient in the context of a web API where the initial contact with the server is from a client who is posting some data (often in the form of some JSON). In this case, the server has not been able to send a token. Normally, a web api would have some other sort of verification - for example, you use JWT, the client app will make an initial connection to the server where it performs some authentication and gets a JWT which it uses in all future API calls.

Often, this is not an issue as you will have separation of concerns. There will be a set of URLs used by a web client which follows the normal request a form then submit the data work flow and a separate API URLs which use something like JWT. There is no need for a CSRF token.

The problem can be when you have vary similar requirements for both. You really don't want to have to maintain two separate sets of handlers and would prefer to just have the one which can be used by a traditional web client and also as an API client. In both cases, a token is used, but they are different in nature.

I did say this was contrived. In reality, I've only come across this sort of issue when developing a new service where I wanted a web client interface as well as the API just for development/debugging purposes. In this case, what I have done is have some javascript in the browser based version which does an initial authentication with the server and gets the JWT which it copies into the web form as just another value. However, I can imagine a situation where you want to support a general web browser based 'traditional' interface and a application which uses HTTP/HTTPS for communication via an API.

To some extent, this is really just semantics. The basic concept of providing a token in web forms to protect against CSRF is not vary different from an API which is using a token for authn/authz purposes. The only real difference is that the CSRF token usually doesn't imply anything more than the fact the response is from the same client the initial form data was sent to while the API token is making assertions about the actual user. Technically, there is no reason the latter cannot be used for the former, provided the server can handle that. The former cannot be used for the latter.


I can not think of a case where CSRF should not be used, apart from unnecessary cases. When you say should not be used are you talking about a case where this will fundamentally break something ? A CSRF token should not break anything so I can not think of such a case

You must log in to answer this question.

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