OWASP CSRF Cheat sheet mentions the "User interaction based CSRF defense", which would also entirely mitigate a CSRF attack. I imagine that the reason OWASP considers it as a Defense-in-Depth (DiD) is because of the impact it has on UX.

I'm quite curious about the "One-time Token" implementation but fail to find any resource that goes more into detail here?

Personally, I would imagine that you generate a unique token for each critical action, associated with the user's specific session. The token can be sent to the user using different methods:

  • via email
  • as part of the API response to the initial request, which should then be submitted as an HTTP header value. Here, the user would then have to perform some interaction (e.g. Clicking a button) that would add the token to the header.

In both cases, attackers will be unable to read the valid token, preventing them from completing their attack. Specifically, with the "as part of the API response to the initial request", during a CSRF attack, an attacker can initiate requests, but not read their responses (thanks to SOP), which would be the key point here.

1 Answer 1


A sensible implementation would be to generate a unique token and send it by e-mail or SMS, or to use One-Time Passwords, be it HMAC-Based One-time Passwords (HOTP) or Time-based One-time Passwords (TOTP). The security benefit comes from the fact that the secret needed to perform the action is sent over a completely separate channel.

If you simply embed a token in a response and add it as a header (after the user has clicked on an extra(?) button), you do not get those benefits. This is actually nothing more than classical anti-CSRF tokens. When you receive a request with a token, it's impossible to tell whether the user has actually clicked on a button. You just get a token within a header. If an attacker knows the token and can set the header, they can do that without needing the user to click on anything. If the attacker doesn't know the token or cannot set the header, then making the user click something is superfluous. You might as well fill in the token automatically.

I'm not sure if “user interaction” is really the key point of the schemes described by the OWASP. Their title seems a bit misleading. If you send a one-time token per mail, and you receive that one-time token in a request, this does not prove user interaction. For example, if an attacker has access to the e-mail account and can set the token parameter in a request, they can perform a classical automated CSRF attack. There's nothing in the HTTP request that tells you whether any user interaction happened at all, let alone whether the legitimate user has triggered the action. The same is true for SMS, HOTP and TOTP. I think a more fitting description would be: CSRF defense based on out-of-band authentication.

  • "If the attacker doesn't know the token or cannot set the header, then making the user click something is superfluous. You might as well fill in the token automatically." - This is where I have to disagree. The confirmation page should not have any JavaScript that automatically attaches the token. When the confirmation button is clicked, JavaScript retrieves the token from the initial requests and makes the second request with the token in the header. If it happened automatically, then there would be no need for a confirmation step.
    – Ben Jost
    Jun 20, 2023 at 19:14
  • 1
    I understand what you're trying to do. My point is that when the server receives the second request, it cannot tell if the user clicked on a confirmation button. If an attacker is able to find out the token and set the header, they can trigger a request which looks exactly like a legitimate request from a user who has clicked on a button. And if the attacker cannot find out out the token or set the header, a CSRF attack isn't possible anyway. So in both cases, the confirmation button doesn't do anything useful.
    – Ja1024
    Jun 20, 2023 at 19:28
  • I think I'm slowly following, thanks @Ja1024! I think I was basically trying to reinvent the Synchronizer Token Pattern here, and that is what likely confused me, as in my mind the first request was protected with a Double Submit Cookie pattern and I wanted to further enhance security here with said implementation.
    – Ben Jost
    Jun 20, 2023 at 19:44
  • Regarding your title suggestion "CSRF defense based on out-of-band authentication.". The Cheat sheet lists, among One-time token, to prompt the user to re-authenticate or complete a Captcha. I guess combining all three would then make sense to call them _"User Interaction Based CSRF Defense"-
    – Ben Jost
    Jun 20, 2023 at 19:52

You must log in to answer this question.

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