reCAPTCHA for PrestaShop: Protecting Your Store from Spam and Bots

Last updated: June 2026.

A PrestaShop store running without CAPTCHA isn't a hypothetical risk — it's a target that automated traffic finds on its own. Bots crawl the web looking for the standard PrestaShop form endpoints, and once they find yours, they start hammering them: fake registrations on AuthController, junk on the contact form, password-combination guessing against the login, reset-email floods. None of it requires anyone to know your store exists. The forms ship with PrestaShop, the bots know the forms, and PrestaShop's stock install has zero bot protection on any of them.

This guide is about closing that gap: what the bots actually do to a PrestaShop store, which specific forms they attack, and how CAPTCHA stops each one. If your worry is the flip side — adding protection without driving real customers away with annoying challenges — that's a conversion question we cover separately in reCAPTCHA without annoying real customers. Here, the focus is the threat and the defense.

What bots actually do to a PrestaShop store

"Spam and bots" is vague until you see it hitting your own back office. Here's how it shows up in a real PrestaShop install, mapped to the part of the store it damages.

The thread running through all of these: the damage is rarely a dramatic breach. It's slow degradation — a customer database you can no longer trust, a support inbox you dread opening, an email reputation quietly sinking. CAPTCHA on the right forms cuts most of it off at the door. (For the more serious end of the spectrum — credential stuffing, order/card abuse, and skimmers — CAPTCHA is one layer among several; see the full security hardening checklist and the anatomy of a Magecart-style attack.)

Which PrestaShop forms to protect — and which to leave alone

The instinct to "put CAPTCHA everywhere" is the wrong one. Bots concentrate on a handful of endpoints, and every form you protect adds a little friction. Protect by where the attacks land, not by gut feel.

Protect first — these are where the bots are

• Registration form. The number-one bot target on any PrestaShop store. Unprotected, it's how the fake-account pile grows. Non-negotiable.
• Contact form. The second-most-hit. This is what stands between you and a Customer Service inbox full of noise.
• Login form. Stops brute-force attempts from turning into both a server-load problem and a compromised-account problem.

Protect next

• Password reset. Closes the reset-email flooding vector that drags your sender reputation down.
• Newsletter signup. Keeps fake subscriptions out of your list.
• Product reviews (if you run a reviews module). Bots post fake reviews to manipulate ratings.

Leave alone unless you have a proven problem

• Checkout. Adding a visible CAPTCHA at checkout is a self-inflicted wound — it raises abandonment on the most valuable page in the store. Only touch it if you're seeing genuine checkout fraud, and only ever with invisible scoring (never a checkbox). The trade-offs here are exactly the "don't annoy real customers" problem covered in the companion guide.
• Search box and add-to-cart. Rarely a real target; the friction isn't worth it.

reCAPTCHA v2 vs v3 vs hCaptcha — which protection to deploy

The version you choose changes both how hard it is for a bot to get through and how much a real customer notices. Three realistic choices for a PrestaShop store:

For most PrestaShop stores the choice is between v3 for invisible scoring and v2 or hCaptcha for an explicit challenge. The current mprrecaptcha module lets you choose reCAPTCHA v2, reCAPTCHA v3 or hCaptcha and set the v3 score threshold; it does not automatically fall back from v3 to v2 on borderline scores, so low-score handling is a tuning and rejection decision rather than a second challenge. The exact score threshold to set, and how to avoid blocking real people, is the tuning side of the job — covered in the companion guide.

Getting CAPTCHA onto PrestaShop's forms — the mechanics

PrestaShop ships no CAPTCHA, so protection means a module. What matters is how it attaches, because that determines whether it actually blocks a submission or just decorates the form.

Step 1 — generate your keys

For reCAPTCHA, register the site at www.google.com/recaptcha/admin; for hCaptcha, at the hCaptcha dashboard. Either way you get a public Site Key (rendered in the page) and a private Secret Key (used server-side to verify). Add both your www and non-www domains. Keys are domain-locked — a mismatched domain can break CAPTCHA validation or block legitimate submissions, so register a separate pair per environment and test that the form fails closed (rejects rather than silently lets submissions through) when the token doesn't verify.

Step 2 — how a proper module hooks in

The important settings are provider, keys, forms protected and v3 threshold.

In a real module, the display hooks render the widget and the action hooks reject the submission before PrestaShop creates the account, message or subscription. These are the relevant hooks from mprrecaptcha source.

public function getHooks()
{
    return [
        'displayHeader',
        'displayFooter',
        'displayCustomerLoginFormAfter',
        'displayCustomerAccountForm',
        'displayNewsletterRegistration',
        'displayGDPRConsent',
        'actionContactFormSubmitBefore',
        'actionSubmitAccountBefore',
        'actionCustomerLoginBefore',
        'actionNewsletterRegistrationBefore',
    ];
}

This is the part that separates real protection from theatre. A bot doesn't fill in your form by hand; it POSTs straight to the controller. So the verification has to happen server-side, before PrestaShop processes the submission — not just as a widget drawn on the page. The key requirement is the same on every version: the token is validated server-side before the account, contact message, login, or newsletter signup is processed. The exact hook names differ by branch — older 1.6/1.7 releases use different front-controller and form flows than 8/9, so a well-built module wires into whichever validated Before hooks exist for your target version (for example the registration, contact-form, login, and newsletter submission hooks). Whichever hook it uses, it validates the token against Google's or hCaptcha's siteverify endpoint and rejects the request before an account or message is ever created. The display side rides on displayCustomerAccountForm, displayCustomerLoginFormAfter and displayHeader/displayFooter to inject the widget and load the script. If a module only renders the badge but doesn't gate the Before hooks, a bot POSTing directly walks straight past it.

Step 3 — verify it actually blocks

Don't assume — test. Submit each protected form as a normal customer to confirm legitimate use still works, then check the provider dashboard to confirm verifications are being logged. The single most common configuration failure is a form that looks protected but whose Before hook isn't wired, so bots sail through while you believe you're covered.

The PrestaShop-specific module choice

Because protection lives or dies on those server-side hooks, the module you pick matters more than the CAPTCHA brand. Our mprrecaptcha module (PrestaShop 1.6 through 9) was built for exactly this: it supports reCAPTCHA v2, v3 and hCaptcha, and on each supported branch it attaches to that version's real server-side submission hooks for registration, contact, login and newsletter — so a direct bot POST is validated and rejected at the controller, not merely hidden from the page. So what does that mean for you? You choose which forms to protect from the back office, leave checkout frictionless, and the fake registrations and contact spam stop arriving — without editing a theme file or touching core, so it survives upgrades. It also exposes a displayGDPRConsent hook so the CAPTCHA script can be tied into your consent flow, which matters in the EU (below).

The GDPR catch you can't skip

Google's reCAPTCHA loads Google JavaScript and sends the visitor's IP and behaviour data to Google's servers — which under GDPR is processing that needs a lawful basis, and several EU data-protection authorities (the French CNIL among them) have flagged it. That creates a real tension for an EU store: block reCAPTCHA until cookie consent and your forms sit unprotected for non-consenting visitors; load it regardless and you have a compliance exposure. There's no universally "correct" answer — it's a risk call. Two practical routes: tie the CAPTCHA into your consent mechanism (the displayGDPRConsent hook above exists for this), or sidestep the Google data transfer entirely by using hCaptcha, which doesn't share data with Google. This is one slice of a wider compliance picture; the broader store-owner view is in the plain-English security guide.

CAPTCHA is one layer, not the whole wall

CAPTCHA stops automated form abuse — fake accounts, contact spam, reset floods, brute-force noise. It does not stop everything, and treating it as your entire defence is a mistake. Distributed bots rotating IPs, traffic floods, and bad actors who've already got past the form all need other layers:

• Bad-bot and IP blocking for traffic that shouldn't reach your forms at all — see blocking bad bots and unwanted traffic and IP bans for problem visitors.
• Admin-side protection — CAPTCHA helps the front-office login, but the back office needs two-factor auth and password policy: 2FA and admin security.
• Crawler-driven load that no CAPTCHA addresses, like the faceted-search query flood: surviving the ?q= flood.
• If something does get through — the incident playbook in data breach response.

The honest takeaway: get CAPTCHA onto your registration, contact and login forms with a module that gates the server-side Before hooks, leave checkout alone, handle the GDPR question deliberately, and treat the result as one solid layer of a hardened store — not the finish line. Done that way, the slow rot of fake accounts and buried support messages simply stops, and you get your customer data and your inbox back.

Frequently asked questions

Which forms should I actually put CAPTCHA on?

Protect by where the bots are, not everywhere. The three to do first are the registration form (the number-one target — this is how the fake-account pile grows), the contact form (keeps your Customer Service inbox usable), and the login form (stops brute-force noise). Next tier: password reset, newsletter signup, and product reviews if you run a reviews module. Leave checkout alone unless you have proven fraud — a visible CAPTCHA there raises abandonment on your most valuable page, and if you must, use invisible scoring only, never a checkbox.

reCAPTCHA v2, v3 or hCaptcha — which should I pick?

v3 is invisible and scores behaviour 0.0–1.0 with a threshold you set, which suits high-traffic or conversion-sensitive forms but needs careful tuning so you don't reject real people on low scores. v2 and hCaptcha show an explicit challenge, which is fine on contact and registration forms where a small click is acceptable. hCaptcha's distinguishing point for EU stores is that it doesn't send data to Google. The mprrecaptcha module supports all three and lets you set the v3 score threshold; it doesn't auto-fall-back from v3 to v2 on borderline scores, so low-score handling is a tuning-and-rejection decision.

My form looks protected but spam still gets through — what's wrong?

Almost always the verification is decorative, not enforced. A bot doesn't fill in your form by hand — it POSTs straight to the controller — so if the module only renders the widget on the page but doesn't gate the server-side Before hooks (the registration, contact, login and newsletter submission hooks), a direct POST walks right past it. Real protection validates the token against the provider's siteverify endpoint before the account, message or subscription is created. Test it: submit each form as a normal customer to confirm it still works, then check the provider dashboard to confirm verifications are being logged.

Why does CAPTCHA "stop working" after I move domains or add www?

reCAPTCHA and hCaptcha keys are domain-locked. If your Site Key and Secret Key were registered for one host, they won't validate on another — so a mismatched or missing www / non-www entry can break validation or block legitimate submissions. Add both your www and non-www domains to the key, and register a separate key pair per environment (staging vs production). Also confirm the form fails closed — rejecting submissions when the token doesn't verify, rather than silently letting them through.

Is using Google reCAPTCHA a GDPR problem for an EU store?

It's a real risk call, not a settled yes/no. reCAPTCHA loads Google JavaScript and sends the visitor's IP and behaviour to Google, which is processing that needs a lawful basis under GDPR, and several EU authorities (the French CNIL among them) have flagged it. Two practical routes: tie the CAPTCHA into your consent mechanism (the displayGDPRConsent hook exists for this), or sidestep the Google data transfer entirely by using hCaptcha. Whichever you choose, never fire the CAPTCHA script before consent if you're treating it as non-essential.

Does CAPTCHA replace other security measures?

No — it's one layer. CAPTCHA stops automated form abuse: fake accounts, contact spam, reset-email floods, brute-force noise. It doesn't stop distributed bots rotating IPs, traffic floods, or anyone who's already past the form. Pair it with bad-bot and IP blocking for traffic that shouldn't reach your forms at all, two-factor auth and a password policy on the back office, and an incident plan if something does get through. CAPTCHA on registration, contact and login is a solid layer of a hardened store, not the finish line.