liveBook · Manning

CAPTCHA

As explained in Grokking Web Application Security

A CAPTCHA is an automated challenge-response test designed to distinguish human users from computer programs.

A CAPTCHA is a challenge-response check that helps distinguish a real person from an automated program. On authentication flows, it can deter simple brute-force tools that repeatedly submit login, sign-up, or password-reset forms. Familiar versions ask people to identify images or read distorted text; newer versions can assess background signals instead. section 8.7 section 8.17

Use a CAPTCHA as one layer of protection, not as proof that every request is safe. Visual challenges can be cracked with computer vision or machine learning, and attackers can pay human CAPTCHA farms to solve them. Pair it with rate limiting and consistent authentication messages so automated guessing and account enumeration are both harder. section 8.7 section 8.14 section 8.17

Add a modern CAPTCHA to a form with a short server-verified flow:

  • Register for a provider such as Google reCAPTCHA and obtain a site key plus a secret key. section 8.7
  • Load the provider script and include a hidden form field for the CAPTCHA token. section 8.7
  • Generate a token when the form is submitted; for asynchronous logins, include it in the JSON request. section 8.7
  • Send the token to the provider for verification from the server. Keep the secret key out of browser JavaScript, or attackers can forge tokens and bypass the check. section 8.7

Protecting password-reset and sign-up forms

An attacker can automate sign-up or password-reset requests and turn an application into a spamming machine by triggering huge numbers of emails. Put a CAPTCHA on these forms, while returning the same acknowledgment such as “Check your inbox” whether an address is registered or not. The CAPTCHA slows simple automation; the uniform response avoids revealing which accounts exist. section 8.14 section 8.17

<script src="https://www.google.com/recaptcha/api.js?render=SITE_KEY"></script>
<input type="hidden"
      name="recaptcha_token"
      id="recaptcha_token">

This form fragment loads reCAPTCHA and reserves a hidden field for the token submitted with the request. section 8.7

<script>
 grecaptcha.ready(() => {
   grecaptcha.execute(SITE_KEY,
     {action: 'form_submit'}).then((token) => {
       document.getElementById('recaptcha_token').value = token;
   });
 });
</script>

This JavaScript generates a reCAPTCHA token and writes it into the hidden field before submission. section 8.7

require 'net/http'
require 'json'

http_response = Net::HTTP.post_form(
 URI('https://www.google.com/recaptcha/api/siteverify'),
 'secret'   => SECRET_KEY,
 'response' => recaptcha_token)
 
result = JSON.parse(response.body)

if result['success'] == true
 puts('User is human')
end

This Ruby example sends the token and server-held secret to the verification endpoint, then checks the returned success value. section 8.7

How Grokking Web Application Security covers it

How deep it goes
Explains reCAPTCHA installation through hidden fields, token generation, and server-side verification, while noting bypasses rather than solving them.
Examples
Uses image-selection and distorted-text widgets, invisible reCAPTCHA signals, authentication forms, and a Ruby verification request.
What it assumes
Introduces CAPTCHA through familiar web widgets, then uses HTML, JavaScript, JSON requests, and Ruby for integration.
What you can do after
Apply it via Google reCAPTCHA by generating form tokens and verifying them server-side without exposing the secret key.
How it connects
Connects CAPTCHA to brute-force attacks, rate limiting, user enumeration, authenticated users, and SSRF defenses.

Also explained in

Compare how 2 books explain CAPTCHA →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Grokking Web Application Security. The section links point to the parts of the book it draws on.