From a UX perspective, CAPTCHA's are bad, bad, bad.

But let's say we have this as a requirement. And it's for a hybrid app (compiled app, but built upon an HTML5 platform).

I'm trying to find out:

  • is bot traffic from an iPhone (or Android device) actually a problem? (or--my theory--is this an outdated hold-over requirement that has been cut-and-pasted into technical requirement documents since 1998?)
  • If so, are there better alternatives that are mobile-centric over yet-another-annoying-CAPTCHA?
  • 1
    Would using something like Google Authenticator be a possible alternative? Feb 7, 2014 at 17:09
  • 5
    Where there's an API, there's a way... Feb 7, 2014 at 17:18
  • 9
    If your app has no CAPTCHA, my emulator can bot it.
    – wchargin
    Feb 7, 2014 at 22:56
  • 5
    @PatrickM The goal of a CAPTCHA or any other method to limit bots is to make it difficult to code for. The method does not need to be perfect just better than most. As the old saying goes you don’t have to run faster than the bear to get away. You just have to run faster than the guy next to you.
    – stoj
    Feb 8, 2014 at 13:18
  • 2
    Can you tell whether the requirements were written by a thinking human or a robot? Feb 9, 2014 at 23:14

19 Answers 19


With regards to your question of whether a bot can actually go and submit a form automatically, this is what I found on an answer on Stack Overflow.

It is comparatively harder to automate data submission within native apps. This is due to the fact that you cannot just write an automated script to discover elements within the source code and then mimic form submission. Also, you'll need to (purchase and) install the application (on a physical device or in a simulator).

That said, one of the comments actually suggests that form submission is much easier on mobile.

It's much easier to do it for a mobile app as they usually talk to a REST API (or some other well-defined API), you don't even need a scraper.

So with regards to your question I don't have a definite answer yet about whether CAPTCHAs are needed.

That said, with regards to CAPTCHAs for mobile devices, there are a number of interesting approaches which have been suggested.

  • The slider CAPTCHA: Luke Wroblewski suggests using a slider CAPTCHA to involve human interaction and prevent automatic submission of content. To quote the article:

    Instead of the distorted text strings that typify most modern CAPTCHAs (above), the sign up form on They Make Apps uses a slider that asks people to: "show us your human side; slide the cursor to the end of the line to create your account." Moving the slider to the right completely submits the form and triggers error validation just like a standard Submit button would.

The slider CAPTCHA

While the above option is web based solution, the easy slide interaction would fit into the mobile paradigm and would fit into the design as well.

  • Another option is to use image recognition to beat automated form submission. This would scale within the design of the app and would also be friendly as the user can click and select the right option. An example of this is given at this link.

Image recognition CAPTCHA

  • MotionCAPTCHA: Another option I found requires the user to trace a path on the screen to complete the CAPTCHA. To quote the article:

    MotionCAPTCHA is a jQuery CAPTCHA plugin based on the HTML5 Canvas. It is requiring users to sketch the shape they see in the canvas in order to submit a form. It could be an awesome alternative to mobile captchas mobile users will surely appreciate that they don’t have to input those tiny numbers.


  • Ring CAPTCHA: This one is an interesting one which requires you to provide a phone number to validate your submission and either sends a text message or calls you to provide a pin code for validation.


  • NuCaptcha: NuCaptcha is another option which uses the traditional CAPTCHA model but is optimized for mobile devices. To quote this TechCrunch article:

    The mobile version of NuCaptcha includes the same simplicity as the web version. But the new optimized mobile Captchas provides a consistent user experience on multiple devices. For example, when a user clicks on a mobile touch screen to solve a Captcha, it will fit perfectly into the space left by the keyboard so that the Captcha can be quickly and easily completed. NuCaptcha does not require Flash or JavaScript; and the company expects to release the HTML5 mobile version of its Captcha technology in early Q4 2011.


That said, none of these options would prevent a human being who is paid to be a CAPTCHA breaker.

  • 6
    @VoronoiPotato I am not very technical but how does that prevent automated bot submission ?
    – Mervin
    Feb 7, 2014 at 18:52
  • 6
    Some of these would prove problematic for blind users. Still a good answer, but I'm just sayin'. Feb 7, 2014 at 20:38
  • 11
    How does the drag-a-slider one work? I can't see any way it could be used to differentiate humans from robots.
    – Robert
    Feb 7, 2014 at 22:08
  • 13
    @MervinJohnsingh I would just short out the whole script. A real capcha has to be enforced on the server
    – Andrey
    Feb 7, 2014 at 22:41
  • 4
    @MervinJohnsingh If the bot is running in a native environment then it would already be doing taps and drags just to get around. If the bot is talking directly to the API then it would depend on what was being transmitted. What characteristics of a drag would tell you if it was done by a real human finger or just a bot emulating one?
    – Robert
    Feb 7, 2014 at 23:41

Snapchat recently added image recognition:

enter image description here

As most captchas, this is also breakable.
But until your app becomes a popular target, this is a pretty nice alternative ;-)

  • 7
    I like this. Not only do you prove you aren't a robot, you are enhancing your brain function. =D Feb 7, 2014 at 18:40
  • 5
    But do see this: kaggle.com/c/dogs-vs-cats . . . . current leaderboard scores (recognition accuracy of 94% making basic use of open-source software) are starting to show that robots will have image CAPTCHA's covered in a few years. Feb 7, 2014 at 19:43
  • 6
    Ah, it has only the image of the obvious ghost up above the directions. That's stupid; presumably the target will always appear there? You're giving the bot software the solution, all it has to do is look for resized/rotated versions of that...
    – Izkata
    Feb 8, 2014 at 3:13
  • 2
    Oh dear I hadn't spotted the tell tale image yet that @Izkata mentions... That really needs to be removed! Feb 8, 2014 at 11:55
  • 10
    This captcha was already cracked, see here.
    – user42730
    Feb 8, 2014 at 13:57

Rather than asking the user to answer a question or choose a correct picture or enter something, another option is to simply delete something from a regular text field.

enter image description here

From an implementation perspective at least, it could not be easier!

  • 2
    I really like this idea
    – Mervin
    Feb 7, 2014 at 21:53
  • 10
    While I did see this approach on a lot of pages, I don't think it would be hard to circumwent this once a robot is trained to do it.
    – SztupY
    Feb 7, 2014 at 22:21
  • It's true, a trained robot might not have too much trouble, and often it is a case of staying one step ahead all the time. With that in mind, some variation in the wording and the position within the form might help a bit. Leave this blank unless you are a...Womble. Don't leave this blank unless you are a...Human Feb 7, 2014 at 22:47
  • It's nice, but will only work as long as bot developers haven't yet picked up on the words used to tell a human to leave the field blank. Feb 8, 2014 at 11:51
  • 1
    Well, this field could use a very suggestive name in the markup (e.g. <input type="text" name="username">), though it would detriment page maintenance. It could also be applied some styling so it is visually overlapped by another field, but still looks right to a conventional bot. Of course, depending on the level of interest from the attacker, this would be relatively easy to circumvent.
    – Kroltan
    Feb 8, 2014 at 17:00

Please DO NOT use most of the examples in the upvoted answer, they completely exclude people with a wide range of impairments (image recognition is useless if you're blind, metaphorical association is useless if you're autistic, maths questions are useless if you're discalculaic etc etc), and they also do nothing at all to remove the problem of humans working in captcha-farms.

Basically, if your verification requires a different type of skill than your content, you're unnecessarily excluding people.

There are other methods available that do not have this disadvantage, such as askismet, honey pot, or if you have something that people really are willing to jump through hoops for, SMS verification.

If you are absolutely set on offloading the responsibility for fixing your site's security issues onto your users, at least offer them a choice, and by choice I don't mean the abysmal 'audio' versions as seen in reCAPTCHA (reCAPTCHA seem to have overlooked the fact that the most common reason for vision impairment, old age, often also results in hearing impairment). So provide multiple CAPTCHAs, and let people choose whether they would prefer to answer a simple question, recognise an image, etc.

Or alternatively you could, as some companies do, simply accept the security issues as your own problem, dispense with user-side attempts at protection, and just accept the implications.

  • 1
    re: your last paragraph...we can dream... :)
    – DA01
    Feb 9, 2014 at 4:36
  • 1
    +1 for 'offloading the responsibility' <cough>. I hate CAPTCHA in all its forms.
    – Mazura
    Feb 13, 2015 at 3:44

Is bot traffic from an iPhone (or Android device) actually a problem?

The problem is not so much 'from an iPhone', but rather that the API you are talking too needs to be protected. At the underlying IP level there is not much you can do to prove what a remote device is, for HTTP it is really just the headers or form data, which a Bot can generate easily. Ie, I don't care what your UX is, I will attack your API directly.

Since you are specifically asking about native apps, a more programmer like approach to your problem would not involve the user, but rather encrypt your payload using a public/private key scheme before transmission. As only your app has the key, bots that attack your API directly are thwarted. Note, I really mean encrypt your payload before sending, not just using SSL (which is not really authenticating the application, but protecting data in flight).

Of course the problem with embedding keys in apps is that apps can be reverse engineered too.

In our lower security apps we have a table of a few hundred keywords and apps (which are often html hybrids) are required to transmit several of these with http form requests. Which ones are to be selected is based on current date using an algorithm that both client and server know. It is then transmitted using ssl. Not perfect, open to reverse engineering of the app, but simple enough to implement.

For higher security apps we store device specific keys on every device rather than a common table, and the server watches/tracks carefully every key use. Of course this isn't practical for mass delivered apps.

  • Of all the comments here, I think you're most on the right track. I want to protect my API!! I like the idea of using a public key on the device to encrypt the traffic - however, if someone reverse engineers your (native) mobile app, they'll get the key. It's harder to do than sniffing REST traffic (which is super easy with Fiddler telerik.com/fiddler), however still not fool proof. I suppose it comes down to the skills of your enemy. At the end of the day, the NSA and their buddies probably break RSA anyway :-( Jul 1, 2014 at 21:08
  • Yep, I also agree - protect your API. Modern versions of Android make it quite hard to attack the underlying SSL communication if you use Cert pinning, do the network stuff in native code to make it more tedious to reverse engineer. Mar 21, 2018 at 16:55

You could use honey pot fields.

They provide a field within the form that is hidden from the user but designed to be noticed and filled in by any given bot.

They can be as simple as a field called 'phone_number' hidden with css. The bot doesn't process the css and sees the field, but the user doesn't.

This would work on both desktop and mobile and has been in circulation for quite a few years now.

Some more detail, including comments that cover accessibility concerns: http://haacked.com/archive/2007/09/11/honeypot-captcha.aspx/

Here Smashing Magazine outline this in more detail as well as dealing with some other Captcha methods:


They also cite social login, image recognition and friend recognition as other more modern methods, all of which could be implemented nicely on mobile, as well as showing in their poll that honeypots are the next most popular choice for their readers after traditional web form Captchas

PS a honey pot field is actually also a CAPTCHA, which stands for 'Completely Automated Public Turing test'. Learning about this principle may help with a general understanding of the underlying ideas.


  • So, the big question, is a honeypot seen by a bot when it's attacking an app (vs. a web site)?
    – DA01
    Feb 7, 2014 at 17:22
  • technically I wouldn't know, but presumably the principle, or at least one of the mentioned principles, could be adapted technically to fit the case?
    – Toni Leigh
    Feb 7, 2014 at 17:25
  • 2
    This is great for the web and what I typically do just because it's so simple. That said, it wouldn't stop bots that do parse CSS. Some easy checks are display: none;, display: hidden; height: 0;, width: 0;, position: aboslute; paired with a huge ABS number in one of the top, bottom, left, or right properties. Feb 7, 2014 at 18:22
  • I think that there are also tricks with hash codes and JavaScript that can augment the honey pot idea, though the link eludes me
    – Toni Leigh
    Feb 7, 2014 at 18:32
  • 2
    A problem with honeypots is that form autocomplete helpers may try to fill the username in. Every human filling in a form is doing so with a computer of some sort, which may be set to automate some of the monotony of filling in forms. If the HTML is only found within the compiled app, someone who wants to run a bot must have specifically sought out the form. If the form contents are being sniffed from the app based on what it submits, honeypot fields won't show up! It's not like a bot that just seeks out WordPress comment forms on the open web. Feb 9, 2014 at 19:39


Since you mentioned HTML5, I'm a big fan of the honeypot approach. Most of your users won't even know it's there. Use all four of the following input fields which you must validate server-side on submit:

  • Required, hidden by CSS
  • Must be null, hidden by CSS
  • Required, hidden by JavaScript
  • Must be null, hidden by JavaScript

The required fields should already be filled in. The fields that must be null should be creatively named "Contact number" or something that a bot would likely assume is a genuine field. Just remember not to use input names that are already in use!

If the user has CSS or JavaScript disabled, you must explain what is required for the submit to be successful, such as "Leave this field alone" or "Leave this field blank".

Note: These must be out of sight but not hidden from the browser entirely, otherwise they won't even register. Test thoroughly!

  • 1
    The honeypot (hidden by CSS method) is indeed great for catching bots. However, I have found that it can occasionally catch real users who allow their browsers to autocomplete form fields (maybe not applicable in a mobile app) - the browser is just another bot. So, on the web at least, you really need to prompt the user with a secondary captcha method in such situations if you want to completely automate this.
    – MrWhite
    Feb 10, 2014 at 18:02
  • You can turn autocomplete off.
    – rybo111
    Feb 10, 2014 at 18:40
  • Yes, we can, but many users don't and it is often enabled by default. Some end users don't even know how to turn it off or even what it is.
    – MrWhite
    Feb 10, 2014 at 18:51
  • 5
    I meant you can include autocomplete="off" on your inputs. Most (all?) browsers support this.
    – rybo111
    Feb 10, 2014 at 20:57

I'm personally a big advocate for a simple math equation for a captcha. For instance, having a fieldset at the end of your form:

What is 1+5?

Have the two numbers generate at random. I have seen a significant decrease in spam/bot form submissions with this method. It seems as if these bots do not have the programming to recognize and solve these equations. Maybe because they're more accustomed/programmed to solve word-based captchas.

Plus from a user experience prospective, these are the easiest forms of captchas I've come across. Simple and not difficult. And they are easy to code/scale (responsive designs) in HTML/CSS.

  • 10
    This only works because it's not (yet?) widely used. Developing an algorithm to solve questions like this is very very simple. Feb 7, 2014 at 20:09
  • 2
    This is usually flagged for being a cognitive accessibility hurdle. That said, I find a regular Captcha to be worse, so it's probably a wash. I do think it's better than the typical cryptic scribbles.
    – DA01
    Feb 7, 2014 at 20:30
  • 5
    @SebastianNegraszus - Although if the numbers were images, the very very simple algorithm you mentioned just got a ton harder. Feb 7, 2014 at 22:08
  • 12
    @CodeMaverick If the numbers are images, then they are either simple to read (so standard OCR software can read them, too) or obscured and difficult to read (so you end up with a traditional captcha and gain nothing). Feb 7, 2014 at 22:55

I'm not a developer so I'm not sure of the security concerns (if there are any), but what about having the user respond via touch input? For example, you could have the user tap a box three times, or maybe do a simple swipe. You could even have the user draw a shape: http://www.josscrowcroft.com/projects/motioncaptcha-jquery-plugin/

  • There is talk of this...namely a swipe action to get to the next part of the form. This is a good option if it works for security.
    – DA01
    Feb 7, 2014 at 17:23
  • 7
    Tapping boxes and swiping things are easy to replicate. That MotionCAPTCHA is entirely clientside JavaScript and offers as much security as a "no bots please" sign.
    – Blender
    Feb 8, 2014 at 11:30


To your first point, I cannot believe there will be much 'bot' traffic to a URL that is only declared within the HTML code embedded in an app. The primary goal of spambots is to plant links back to other sites, and there's not much point doing that on pages that are not themselves indexed, and no point at all on forms that do not affect content.

Whilst it is possible to disassemble the app or sniff the requests, there would need to be some purpose to a bot created from the information. If the objective was simply to swamp your server with traffic, sending incorrect CAPTCHA data often enough would be sufficient. Without knowing what you seek to protect, I cannot say whether a CAPTCHA is necessary.

Mobile-Centric Alternative

As the only known purpose of the CAPTCHA is to comply with a robotic request from the specification drafters, a sufficiently foolproof CAPTCHA would be the following text instruction:

Please hold your device in your left hand.

As we all know, computers do not have hands and always follow instruction so when faced with this they will probably like self-destruct or something. Stands to reason.

(This is mobile-centric as desktops are typically too heavy to hold in one hand.)

This text genuinely ticks all the key boxes for an alternative CAPTCHA:

  • Delays completion of the form by all humans
  • Alienates the disabled
  • Makes zero difference to the form fields submitted, thus requiring no server-side programming
  • Is easily circumvented by anyone with genuine malicious intent

just like other answers here, like the one where you have a slidey thing because computers don't have fingers.

An enhanced version of this would be to place the word left in a blurry image of a particularly hard to read font in an eye-watering colour combination, which will achieve:

  • Ruins the design

You could try NoMoreCaptchas.com to auth the user. Its done w a new type of technology called BioChronometrics. This is all passive to the user based on user behavior.


A very simple approach that worked for me in production was to add a checkbox field that was hidden via style definition (CSS) and not via attribute type="hidden".

If the field is checked on submit, the probability is high that a robot checked it, if not a user submitted the form.

This solution is not 100% safe but very very easy to implement, effective and more important: user friendly!


Bot Traffic

is bot traffic from an iPhone (or Android device) actually a problem? (or--my theory--is this an outdated hold-over requirement that has been cut-and-pasted into technical requirement documents since 1998?)

Bot traffic to an API server is not usually from your iPhone or Android device, instead they come from bot farms, that nowadays(August 2020) are a collection of compromised servers and iot devices working together or individually to attack/crawl/scrape an API server.

I don't discard that mobile devices can also be compromised to act as bots, but that isn't usually the case. Unauthorized traffic that is reaching the API server from a real mobile device it's generally from a cloned/tampered version of the official mobile app available in the iOS and Android stores.

You also have the situation where an attacker may be performing a MitM(Man in the Middle) attack against the original mobile app installed in a device he controls in order to manipulate the traffic in both directions. An example of a good open source tool for doing a MitM attack is mitmproxy:

An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.

This tool can be used to exfiltrate data or to gain access to privileged features/data that the mobile app doesn't expose, but the API exposes. Another form of achieving the same is to use an instrumentation framework to hook at runtime on the original mobile app. An example of such a framework is Frida:

Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.

Bad bots traffic is indeed a very serious issue for API servers, and they are very hard to mitigate, because while it's easy to identify/authenticate who is in the request, it's very hard to do the same for what is doing the request.

Wait, I don't get it, but as you a lot of others are not aware that this difference exists or have a misconception about it. Until 2018 I was one of that developers, therefore I would like to first clear this common lack of knowledge or misconception about the difference between who and what is accessing an API server.

The Difference Between WHO and WHAT is Accessing the API Server

I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

So think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.

Possible Better Alternative

If so, are there better alternatives that are mobile-centric over yet-another-annoying-CAPTCHA?

You can use the Mobile App Attestation concept in conjunction with the Android SafetyNET and the iOS Device check in order to achieve a very high degree of confidence that you truly have locked down your API server to your genuine mobile app. Please read my answer to the question Restrict API requests to only my own mobile app for more details.

Do you Want to go the Extra Mile?

In any response to a security question I always like to reference the excellent work from the OWASP foundation.


OWASP API Security Top 10

The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.

For Mobile Apps

OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

OWASP - Mobile Security Testing Guide:

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.


is bot traffic from an iPhone (or Android device) actually a problem?

Yes, and anyway your servers can't dissociate traffic from a PC and traffic from a smartphone if the spammer has done things correctly.

If so, are there better alternatives that are mobile-centric over yet-another-annoying-CAPTCHA?

There is no alternative to captcha.

Things like the concept that was linked in another answer are totally incomparable to a captcha. Captcha is to that kind of solution as strong password hashing is to obfuscation. Anyone with a few reverse-engineering skills will be able to break it.

Captcha (visual or audio) is relying on the limited power of computers nowadays, and thus, their limited capabilities in image or sound recognition. Other solutions are simply relying on the fact that the spammer may be too stupid to make a correct spambot.


When the technology involved in voice recognition has evolved to an acceptable level, it would be a real alternative to touch input CAPTCHA. Sadly to say, we are not quite there yet, if we read the findings of Kapil Chalil Madathils et. al. article Evaluating the usability of CAPTCHAs on a mobile device with voice and touch input. They concludes that...

The results indicate that users may not be satisfied completing CAPTCHAs by voice, at least when using the current Dragon Mobile SDK voice recognition software. Incidentally, Siri - the speech recognition application and personal assistant developed for the iPhone - was not availablefor use at the time of this study. Our results also suggest that Confident Touch is an effective and usable CAPTCHA for mobile devices. An additional benefit to this CAPTCHA is its space saver version that takes up less space on a web page and mobile screen. Overall, our results generally support the use of image-based CAPTCHAs where this is feasible. Some participants in our study appeared frustrated when attempting to recognize the distorted characters in Google's CAPTCHA, and a few even mentioned their frustration with similar text- based CAPTCHAs encountered online. The scores on our usability measures for Google's CAPTCHA, however, werereasonably good.

But things move quickly in this world, and the fact that Siri wasn't tested brings hope for the future of voice recognition CAPTCHA. Until then, image based CAPTCHA is the best option.


How about generating two random numbers between 0 and 10 and asking the user what is the sum of those numbers.

  • 1
    And how do you prevent a bot from entering the sum? The solution doesn't scale, the more sites use it, the more bots will start including the very simple algorithm for knacking.
    – Rumi P.
    Feb 11, 2014 at 11:44

Firstly, to secure your API, add a new inbound rule to your firewall that only allows connections to your API's IP address and Port from your Web Server's IP address / Local network IP range (if developers or other machines need access), even if they are hosted on the same machine. This does of course mean that you need to assign a unique port to your API, but it shouldn't be a problem if your API isn't public. This will prevent any bots from making requests directly to your API.

Secondly, add Facebook or Google verification to your signup process. This means that you will automatically benefit from any new Captcha solutions that are implemented by them in the future. And it's great for users because they won't have to remember yet another password.

Captchas are a real eye sore and really hard to read sometimes, and judging by the comments above, definitely not worth the effort.

  • 1
    This assumes that users a) have Facebook / Google accounts, and b) are prepared to associate their accounts with this service. You cannot guarantee either of these things.
    – JonW
    Dec 30, 2014 at 14:26
  • Sure, but it's becoming very common for websites to use them. It would be interesting to have actual stats around this, to make an informed decision. Dec 31, 2014 at 1:21

One of the options can be asking user to input the current-mobile number, sending an OTP to the mentioned number and reading it automatically (user should not be allowed to enter the same manually).

  1. Try having OTP. Ask the user to enter his/her mobile number.
  2. Simple math question.
  3. Have a checkbox stating I'm human
  4. Find odd one out
  5. The Trivia Puzzle - For ex: what color is sky?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.