I was testing rate limit on the login page of a site. It was captcha protected. I could not even intercept the POST request on burp, so from Google Chrome I looked at the logs and in its POST request, it was passing this captcha parameter and also other recaptcha requests.

So then I ran Firefox again which is connected with burp. This time I used private tab and tested the same login page. To my surprise there were no recaptcha requests, also no captcha parameter or value in login POST request. It allowed me to test unlimited payloads and still giving right response for password.

Can anyone explain to me what is happening here? Why running browser on private allowed me to bypass recaptcha? I know this is a vulnerability but how and what is causing it?

1 Answer 1


Running Firefox in private browsing, it will have enabled Tracking protection. With tracking protection enabled, it won't be loading recaptcha (since that serves as a tracker for Google). You should see a partial shield on the url bar noting that.

Now, by not loading recaptcha, it is relatively common that the page doesn't even show a sign that there should be a recaptcha button there (bad idea, the user may not notice that something required was blocked).

However, the real problem is that they are not validating recaptcha answer. The page including the recaptcha must verify the provided answer by asking recaptcha (ie. Google) if it is valid. Apparently, they forgot to do it (or they disabled it in advance for your pentesting), and that makes possible to submit the login attempts completely ignoring the captcha. It should have complained instead that you didn't solve the captcha.

  • tl;dr: You could login because the site has a bug.
    – user163495
    Sep 5, 2019 at 10:51

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