One defense that developers use to protect against a CSRF attack is to implement a CAPTCHA in critical steps. A CAPTCHA ensures that a human is at the keyboard approving the activity. But I've heard that CAPTCHAs have been broken. Sure, I can see how the CAPTCHA-defeating software could be used by bots to post spam to forums and such. But I don't see any techniques that could be used in a CSRF attack.

Can anyone explain exactly how an attacker can defeat a CAPTCHA in a CSRF exploit?

To clarify ... I understand how CSRF works and the various methods of protecting against them. What I want to know is how the CAPTCHA protection can be defeated.

  • How would this be implemented on a AJAX / Javascript application? Do you have samples, or links? Commented Feb 15, 2012 at 22:25

4 Answers 4


A CAPTCHA would not be defeatable as an XSRF mitigation except by brute force, or another type of attack (eg clickjacking to frame the target site's UI in a redressing context). Image analysis could not be applied because an attacker from another site doesn't have read access to the content in the CAPTCHA.


One defense that developers use to protect against a CSRF attack is to implement a CAPTCHA in critical steps.

I don't know the developers you're talking about, they don't sound very sane.

You get the same benefit without the cost in degraded user experience by simply sending a token to the client and having the same token checked when it comes back to the server. (You can also get much more entropy in such a token than a user could comfortably type in a CAPTCHA, making it brute-proof.)

Per-session synchronizer token pattern

  • +1 for the answer and bonus Synchronizer token info. Nice. Unfortunately, Synchnronizer token is more beatable than a CAPTCHA. All the attacker has to do is automate all the steps along the way using JavaScript.
    – Rap
    Commented Feb 16, 2012 at 0:48
  • 2
    Well, granted, if the attacker already has access to script into your domain (XSS), then a synchronizer token ain't going to help you... but then you have much, much worse problems then XSRF to worry about. Even a CAPTCHA wouldn't provide much practical defence since the XSS attacker can just wait for you to solve it and then hijack your interaction with the site afterwards.
    – bobince
    Commented Feb 16, 2012 at 12:36
  • they don't sound very sane: It's one of the methods OWASP suggests in high risk situations (eg when changing a password, adding a new admin user, etc). It may make sense in case the token is leaked somewhere (logs, etc). It may also somewhat limit the impact of XSS. I would prefer to use a password here though, because of OCR.
    – tim
    Commented Mar 6, 2016 at 12:18

CAPTCHA can be broken by using image/audio analysis.

In it’s most basic form Optical Character Recognition (OCR) a technology that has been around years. OCR reads an image and looks for characters it understands and translates that to text… Bingo, a method for breaking image CAPTCHA.

Likewise speech analysis, we have it on phones, gaming consoles etc. Again the technology has been around for years.

Image verification CAPTCHA often uses noise in the image to make it harder but filtering out the noise is not that hard. Really it only takes a bit more processing.

CAPTCHA is still a good deterrent because it adds complexity and is generally well accepted by users, but it is not a silver bullet.

Also another way CAPTCHA can be broken is by humans. A few years back I believe there was a few large botnets that were collecting the answers to CAPTCHA codes by serving them up to infected machines.

To protect your CAPTCHA or any manual verification system, limiting the time the codes are valid for is a first defence.

Hope that helps.

  • 1
    Thanks, @Bernie. I know many CAPTCHAs can be beat, but can it be beat during a CSRF attack and if so, how?
    – Rap
    Commented Feb 16, 2012 at 0:50

Using a CAPTCHA can be an effective method of mitigating risk of a successful CSRF attack. There are ways of defeating CAPTCHAs in general, but if you pick a solid implementation then they are effective. However, they do result in a fairly negative user experience (every time you're going to do anything sensitive, you need to enter a CAPTCHA = lots of very unhappy users).

A better idea is the use of validation tokens, as they are transparent to the user. This is generally regarded as the preferred-method of CSRF mitigation. You can also combine this with a weak-referrer-check if you'd like multiple countermeasures in place (see here: https://stackoverflow.com/questions/9283628/should-i-use-http-referrer-validation-or-token-verification-to-prevent-csrf-atta/9283830#9283830).


As always: it depends. In this case it depends on the actual Captcha implementation. Because if the Captcha can be solved by also forging the response or it can be tricked with replay attack, it’s won’t protect you against CSRF either.

But let’s assume you use a secure Captcha. Then to solve a Captcha an attacker either needs to be able to read it somehow and solve it or they brute force it.

Reading the challenge is not possible due to the Same-Origin Policy. So general Captcha solving methods like OCR or human solving doesn’t work here. Then the last viable attack is brute forcing.

If that’s all not possible, using a Captcha can prevent CSRF attacks. But as already said, there are also other, less annoying solutions to mitigate CSRF attacks.

You must log in to answer this question.

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