In this question on software recommendations, the OP asks for an alternative to Google reCAPTCHA because "for a security reasons also we don't want to depend on any out side services".

As far as I know, you ask Google for a CAPTCHA, you display it, you send the user’s input to Google who tell you if the input was correct or not.

Where’s the possible insecurity?

It's not like you send Google the user's log in, password, d.b.b, bank account number or any other sensitive information.

I suppose that a truly determined attacker could use some man-in-the-middle attack, but why? CAPTCHAs are generally used to prove you are not a bot and not as login credentials.

Am I missing something? Is the OP correct to be concerned or is he just going to cause himself a heap of extra work, possibly by trying to implement his own system which he believes to be safer than Google's because ... security through obscurity?

  • 20
    IMHO, the OP's belief that by implementing his own CAPTCHA system is wrong. As a security professional, I always recommend the use of widely accepted, regularly audited and patched algorithms and implementations for tasks like CAPTCHAs, Encryption and Random Number Generation. Commented Sep 28, 2015 at 13:15
  • 3
    @feral_fenrir The OP was asking on software recommendations, so they clearly want to use an existing captcha solution, if there is one fitting their requirements. Not wanting to use a SAAS solution is understandable, both from a security point of view (including javascript from an untrusted source is self inflicted XSS) and from a privacy point of view (google is tracking users). Commented Sep 29, 2015 at 9:55
  • That comment isn't specifically targeted at Google. All I would take from that comment is that they don't want to use any third party services.
    – MrWhite
    Commented Sep 30, 2015 at 10:51
  • 1
    Recently, captcha issues abound for those who have tracking protections turned on in their browsers. Myself included, which suggests more than just "website sends to google / google sends back to website, and website authorizes. If it were that way, why would captcha be blocked while tracking is turned on, and work when tracking is turned off?
    – TG2
    Commented Mar 22, 2019 at 0:49

3 Answers 3


Well, there could be a couple of concerns:

  • Denial of service: In case the Google reCaptcha system somehow goes down, your users will probably not be able to authenticate anymore. This could also happen if they implement some kind of update, which breaks the whole system.
  • External JavaScript libraries: when using Google reCaptcha, you need to include some JS libraries. In case Google wants to execute some XSS attack, you have just made it a lot easier for them.
  • Tracking: anyone clicking through the reCaptcha 'consents' to be tracked by Google. This may impact your user's privacy, as well as provide a means for Google to track traffic on your website.

However, as mentioned in this answer, they probably care more about their reputation than about compromising your website. Although I doubt that when it comes to the 'tracking' concern.

  • 7
    Note that it wouldn't have to be Google who wanted to execute an XSS attack, but anyone who gained ability to MITM them. See the recent DDOS attack on Github, allegedly orchestrated by the Chinese government injecting XSS into Baidu advertising code.
    – IMSoP
    Commented Sep 28, 2015 at 17:14
  • 1
    Or maybe a side-swipe Denial of Service attack: MITM the connection/s between the user/s and the reCaptcha service and dynamically modify every user response a little so that validation always fails. :) Commented Sep 29, 2015 at 4:29
  • 1
    Whether the user 'consents' or not, the important thing from a security POV is that they are tracked by Google! Using a third party for all or part of your authentication means as you say that third party in effect is watching your front door and noting who comes in. This isn't necessarily a problem, but when it is a problem there isn't really a workaround. Commented Sep 29, 2015 at 8:30
  • Actually, an XSS by a malicious third party might not need a Google compromise or MITM to be carried out. The google CDN serves old (and thus vulnerable) versions of commonly used js libraries. So, if you're plugging a hole in your Content-Security-Policy just to allow google, and if you have code that'd be XSS-vulnerable without CSP, you'd end up with no effective protection: git.io/vcYdc this example is for ajax.google.com, recaptcha uses apis.google.com instead. I'm not aware of vulnerable code hosted there, but this doesn't mean that we shouldn't be cautious (what's the threat?)
    – berdario
    Commented Sep 29, 2015 at 10:36
  • 1
    On the side note - the tracking is the ultimate source of Google's reputation. They wouldn't be where they are now without all this tracking going on. Only switching the tracking off would ultimately harm the rep.
    – Pavel
    Commented Sep 29, 2015 at 14:17

It isn't clear from the OP's question, but it is possible that for security reasons the whole system is not able to communicate with third party networks. The OP may wish to have a system that he can implement server-side because the server, and potentially the clients too, are unable to connect to Google, or anywhere else on the Internet. The security benefits of not being connected to the Internet when you don't need to be are widely known.

  • An excellent point, maybe the OP will clarify this for us
    – Mawg
    Commented Sep 28, 2015 at 15:07
  • OP of other question says "don't want to" , not can't Commented Sep 28, 2015 at 15:07
  • 6
    While this may be possible, I think it is highly unlikely to require a captcha at all in an intranet (if no one can connect to the internet) - You have usually a countable number of users in the intranet and it is usually easy to identify them by IP-Adress/Subnet or similar. So no real need for captchas.
    – Falco
    Commented Sep 28, 2015 at 15:21
  • 8
    @Falco The number of users on the internet isn't just countable, it's finite. :) Commented Sep 28, 2015 at 18:16

According to Egor Homakov's blog:

  1. Google reCAPTCHA relies on a whitelist based on your previous online behavior (cookies) which thing does not make the task difficult for bots as the legacy flow is still available and old OCR bots can keep recognizing the old CAPTCHA.
  2. The replacement of the the traditional challenge/response procedure by this cookie whitelist makes the whole service vulnerable to attacks via clickjacking.
  • I don't think that the OP was concerned about how well reCAPTCHAs work at identifying humans v. bots. I think the question is about whether calling Google's CAPTCHA implementation adds additional security risk. Commented Sep 28, 2015 at 19:33
  • 1
    @NeilSmithline Are not the two points I took from that blog talking about security risks?
    – user45139
    Commented Sep 28, 2015 at 19:34
  • 2
    Not in the same way. Consider an application with no CAPTCHA. Adding CAPTCHA might make the app more secure, but shouldn't make the app less secure. Your two bullet points explain why CAPTCHA might not make the app more secure but, at least to me, the OP is asking whether adding CAPTCHA makes the app less secure. Commented Sep 28, 2015 at 19:38
  • ... makes the whole service vulnerable to attacks via clickjacking: this answers : the OP is asking whether adding CAPTCHA makes the app less secure
    – user45139
    Commented Sep 28, 2015 at 19:40
  • How does usage of a cookie whitelist make a page any more vulnerable to clickjacking than any other method of dynamic interaction? In general, clickjacking is a UI issue, so anything that involves interaction with rendered components on a website has some potential clickjacking vulnerability.
    – JAB
    Commented Sep 29, 2015 at 13:20

You must log in to answer this question.

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