PrestaShop bot protection, request limits and CAPTCHA

What we would do

We would identify the failing journey and the requests behind it before installing another protection layer. The right route depends on your existing shop: its PrestaShop and PHP versions, hosting and proxy setup, theme, modules, integrations, recorded data, markets and the people who will review refusals. Keep working controls and check whether an installed module already provides the missing step.

For a shop struggling to serve pages, start where requests can be stopped before PHP. For unwanted submissions without a capacity problem, start with the affected form and its server-side validation. For a disputed account or order, review the evidence before restricting access. The decision table below helps you choose the starting layer.

Reproduce the relevant journeys on a private staging copy with your actual theme, checkout and modules, isolated from customer emails, live payments and fulfilment exports. Save the current configuration, rehearse the refusal and recovery tests, then introduce the change in an agreed live window. Use a narrow production trial to check actual proxy addresses, crawler traffic and edge behaviour that staging cannot reproduce, with a named reviewer and a way to reverse the rule.

If you need an exposure assessment, the PrestaShop Security Audit & Hardening Report provides prioritised findings and a remediation plan; implementation is scoped separately.

Identify requests before you block them

Start with the affected action: slow category pages, repeated logins, fake registrations, spam messages or growing empty carts. Record timestamps, routes, query arguments, status codes, response times and the network addresses involved. Compare them with PHP workers, database activity and legitimate orders.

Search crawlers, social-link preview fetchers, payment callbacks, monitoring and scheduled jobs may all be useful automation. Scraping, credential stuffing, vulnerability probes, fake accounts and abusive submissions need different controls. A claimed user agent, VPN address, hosting network or country is not proof of abuse.

Use request logs for request rates

Review the web-server and edge logs. For a conventional combined access log, these examples count logged requests by the first address field and requested path. Confirm the actual log format first; a proxy address in the first field needs different handling.

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

These totals cover the file, not a defined rate interval. Filter a suitable time window and separate static assets, page requests, form submissions and retries before selecting limits. Generic probes such as /wp-login.php or /.env deserve investigation but do not establish a successful intrusion.

Native statistics can provide clues, depending on installed statistics modules. Under Stats, inspect available Visitors online, Visitors origin, Pages not found and Best-viewed pages panels for a change worth tracing in request logs. The connections table is not a complete HTTP log: recognised bots may be excluded and connection records are reused within a 30-minute window. The following read-only query counts recorded IPv4 connection sessions for shop 1, using the example ps_ prefix.

SELECT INET_NTOA(c.ip_address) AS recorded_ipv4,
       COUNT(*) AS recorded_sessions
FROM ps_connections AS c
WHERE c.id_shop = 1
  AND c.date_add > DATE_SUB(NOW(), INTERVAL 1 DAY)
GROUP BY c.ip_address
ORDER BY recorded_sessions DESC
LIMIT 50;

Change the table prefix and shop scope to match your installation. Run read-only reporting through Advanced Parameters > Database > SQL Manager or an authorised database tool. This legacy numeric IP storage is not a complete IPv6 traffic report. Parsed browser metadata in the guest tables is not a raw User-Agent log.

Third-party visitor tables can also deduplicate observations. Counts of those rows measure collected records, not requests, visits or a reliable device fingerprint. Correlate them with request logs before acting.

Turn warning signs into a testable diagnosis

Keep a small incident record with a redacted request example, its time zone, the affected route and the observed side effect. Give your host and developer the same interval so that they can compare edge events, access logs and application activity without exchanging entire customer records.

Verify crawler identity and proxy addresses

A bot can send Googlebot in its User-Agent. For a crawler exemption, match the appropriate current published IP ranges or use forward-confirmed reverse DNS.

1. Take the original client IP from a trusted log field.
2. Reverse-resolve it.
3. Check the operator's documented domain suffix at a real domain boundary. A hostname ending in googlebot.com.example.net does not belong to Google.
4. Forward-resolve the returned hostname and confirm the original address is among the results.
5. Cache and refresh verification data, and handle lookup failures without silently creating a permanent exemption.

Use the Google crawler verification procedure for its crawler categories and current range files. Other operators have their own procedures. Verification establishes identity, not unlimited rendering capacity.

Configure trusted reverse proxies before enabling per-IP limits. The origin must accept forwarded client-address headers only from trusted infrastructure, and that infrastructure must overwrite untrusted incoming values. Syntactic IP validation does not authenticate CF-Connecting-IP, X-Real-IP or X-Forwarded-For.

Test the address seen by the edge, web server, PHP and your blocking integration. Check both IPv4 and IPv6. An incorrect setup can group every customer under a proxy's address or let clients choose the address that is logged.

For country rules, confirm how the location is obtained. A trusted edge country header, a current GeoIP adapter and a stored country cookie have different reliability. Do not assume a legacy GeoIP API works with modern GeoIP2 code.

Choose controls at the right layer

PrestaShop can generate robots.txt under Shop Parameters > Traffic & SEO > SEO & URLs. Review the generated content and your actual routes. Do not put secrets in robots.txt or treat a disallowed path as private. Sitemap inclusion depends on your sitemap module and configuration.

Keep payment webhooks, order validation, 3-D Secure returns and monitoring in your route inventory. Record each route's purpose, method, expected response and owner before changing its treatment. Verify provider signatures and current delivery requirements. A broad bypass for anything that claims to be a payment client is unsafe.

A rate limit should use an explicit time interval and measured workload. Configure a suitable rejection status, normally HTTP 429 for throttling, and a usable retry response. Consider office networks, mobile carriers, accessibility tools and legitimate automated clients. Count the action you intend to limit: including product images and scripts in a login policy can make an ordinary page load consume the allowance. Distributed traffic can also overload a route while each address stays below its individual limit.

For application limits, verified-crawler refresh jobs, JavaScript challenges and the independent capacity guard, use the Security Revolution help page; its request firewall defaults to monitoring, so enabling a feature alone is not proof of enforcement.

Contain expensive faceted-search requests

A category request such as /category-slug?q=Brand-Brand-A/Color-Red can trigger filtering work. Many distinct combinations may produce little cache reuse while occupying PHP workers and database connections. Confirm the cost in your own request logs and profiles.

Disabling ps_facetedsearch can remove its interface and reduce filtering work. It does not stop clients requesting URLs they already know, or prevent those requests from reaching the category controller. A blanket block on every q argument can also break search, module routes, APIs and saved customer filters.

Worked example: the server is busy, but sales are unchanged

Suppose your logs show changing brand and colour combinations on a category while PHP workers remain occupied. Group the requests by category as well as by full URL: a long list of different URLs can hide a common expensive route. Compare filtered and unfiltered responses and ask the host where time is spent. If combinations are rarely repeated, adding each response to a page cache may add storage and writes without much reuse.

Trial the rule on that confirmed category, keeping a representative direct filtered link and a normal browser filtering session as controls. If edge challenges increase but origin work remains high, inspect the requests still getting through: verified crawlers, clients using the AJAX marker, passed challenges or direct-origin traffic. That evidence decides the next change; a higher challenge count alone is not proof that the bottleneck has gone.

Build a narrowly scoped edge rule

1. List the actual faceted-category paths, including shop subdirectories, languages and rewritten routes. Start with a small explicit set.
2. Match GET requests carrying the relevant facet argument. Test empty arguments and repeated values too.
3. Decide how verified crawlers are treated inside this specific rule. Do not create a broad skip for unrelated security rules.
4. Check AJAX filtering. Returning a challenge HTML page to a request expecting JSON can break the interface.
5. Trial a Managed Challenge and inspect customer behaviour and remaining origin load before widening coverage.

This expression illustrates a store whose confirmed category path is exactly /en/12-home-accessories. Use only paths confirmed for your shop. If facets are encoded in a rewritten path rather than a q argument, this expression will not match them; build and test a matcher for those actual routes.

http.request.method eq "GET"
and http.request.uri.path eq "/en/12-home-accessories"
and len(http.request.uri.args["q"]) >= 0
and not cf.client.bot
and not any(lower(http.request.headers["x-requested-with"][*])[*] eq "xmlhttprequest")

The missing-key comparison evaluates false when q is absent. See Cloudflare's rules-language value behaviour. The AJAX marker is spoofable and some legitimate AJAX clients omit it. Any exception based on it leaves an available bypass. A verified-bot exception also leaves that crawler's load reaching the origin.

Custom rules and Managed Challenge are available across Cloudflare plans. Regex matching needs Business or Enterprise; the custom-rule Log action needs Enterprise. See custom-rule availability. Without Log, use available analytics and a controlled narrow trial.

Use cf.bot_management.score only with the Bot Management entitlement. A possible trial targets scores greater than 1 and below 30; treat score 1 separately if appropriate. Scores describe automation, not malicious intent. The legacy threat score is not a substitute. Check Cloudflare's feature interactions before combining controls. Free Bot Fight Mode is domain-wide and cannot be skipped by custom rules.

Challenges may require interaction, cookies or JavaScript. Test direct links, mobile browsers and privacy tools. Visitors who pass a challenge can still generate origin work.

Close the origin bypass

Proxy public web hostnames through your chosen edge service. Keep mail and other non-HTTP DNS records configured for their actual service. Audit any records that reveal the web origin, and restrict origin HTTP/HTTPS access to the edge's current published addresses plus narrowly justified operational access. Preserve certificate renewal, health checks and rollback access. Use valid HTTPS between edge and origin.

Review crawler access, search visibility and useful referrals after changes. If the existing filter works for shoppers, keep it while you validate the traffic controls. Consider a different filter architecture when catalogue navigation also needs reworking, with deliberately selected landing pages in place of arbitrary indexable combinations. It can reduce discovery of arbitrary combinations, but old URLs and AJAX endpoints still need controls; use the Filter Revolution help page for that module's routing and SEO-page workflow.

Protect the origin without an edge WAF

Use server limits when you control Apache or Nginx, or ask your host to apply them. Apache .htaccess supports suitable request conditions when overrides are allowed; rate-limiting modules such as mod_evasive require their supported server or virtual-host configuration. User-Agent blocks can express a crawler policy, but empty or named agents are not inherently malicious.

In Nginx, limit_req_zone belongs in the http context. Apply limit_req where the expensive request is actually processed. Friendly URLs may internally redirect to index.php, so test the final location and route arguments. The following are directive examples to integrate into an existing configuration, not a complete replacement server block:

# http context: illustrative measured-policy starting point
limit_req_zone $binary_remote_addr zone=shop_requests:20m rate=10r/s;

# In the applicable request-processing context
limit_req zone=shop_requests burst=40;
limit_req_status 429;
limit_req_dry_run on;

Use the Nginx request-limiting reference to check directive support and inheritance. With limit_req_dry_run on, excess requests are recorded but not refused. After checking logs and legitimate journeys, set limit_req_dry_run off, run a configuration test and reload only a valid configuration, keeping the previous configuration for reversal. Login and expensive-filter routes may need separate policies; a regex for /search does not cover all category requests with q.

For fail2ban, log an explicit server-side authentication-failure event and test the filter against actual failed and successful logins. Include a normal password mistake followed by a successful retry, and confirm how an authorised person releases a mistaken block. Native customer login can return an error form with HTTP 200. A filter looking only for login POSTs returning 401 or 403 can miss the failures. Never log passwords or CAPTCHA secrets.

A scoped application redirect as a fallback

If a selected direct facet URL should resolve to its unfiltered category, a developer can implement an early Dispatcher redirect. It still starts PHP and is less useful against connection exhaustion than an edge or server control.

1. Resolve or explicitly match the category for the current shop and language. Limit the intervention to GET requests with the relevant facet argument.
2. Exclude search and module/API routes. If preserving AJAX requests, test the actual marker and accept that bots can copy it.
3. Parse REQUEST_URI, remove only q and rebuild the query with http_build_query(). Retain other arguments, the shop base path and the language prefix.
4. Use the configured shop origin, prevent loops and stop processing after the redirect. Otherwise continue the normal dispatch.
5. Test with a temporary redirect. Use a permanent 301 only if removing the filtered destination is intentional. Review existing Dispatcher overrides and rebuild the relevant class index after deployment.

Saved links lose their selected filters within that scope. Review valuable indexed filter pages and map them deliberately rather than assuming every combination has no search value. Combining a redirect with an edge rule still removes the filter after a client is allowed through.

Protect forms with server-side validation

Choose forms from observed abuse: registration, contact, login, password reset, newsletter, reviews or checkout. Search and add-to-cart can also suffer resource abuse, although an interactive CAPTCHA is not automatically the right remedy.

Stock forms do not all include CAPTCHA, but they are not devoid of controls. Password recovery includes timing checks; versions of the official contact module use a honeypot and an expiring token. Keep those controls when adding another layer. Test browser autofill and assistive tools against any added honeypot: a filled hidden field deserves validation, rather than an assumption about who submitted it.

Select the provider and mode, create the matching keys in that provider's console and enter them in the module's configuration. Enable protection for the intended forms, then run the valid-submission and refusal tests below. The site key is public; keep the secret on the server. Use the correct key type, environment and hostname configuration. Registering a reCAPTCHA root domain covers that domain and its first-level subdomains, including www; unrelated domains need their own allowed configuration. Follow Google's domain rules and the separate rules of any other provider.

The server must verify the token and the expected context before creating an account, sending mail, subscribing an address or authenticating a customer. Check success, hostname, action and score where applicable. Never trust a client-side success flag or a rendered badge alone.

Keep customer login and employee login as separate requirements. A working front-office challenge says nothing about access to the back office; staff authentication needs its own checks and recovery procedure.

For developers, check the exact core contract for each supported version. Modern registration combines actionSubmitAccountBefore results as booleans. The native customer login calls actionAuthenticationBefore but does not use its return value as a refusal. Merely registering a similarly named hook is insufficient. Checkout login, guest registration, AJAX forms and custom themes need their own route coverage.

Native account registration does not generally require an email activation link. Welcome mail, account verification and newsletter double opt-in are separate workflows.

For provider settings, supported forms, optional v3-to-v2 fallback and conditional script loading, use the reCAPTCHA & hCaptcha Protection help page. Its listed form coverage is contact, customer login, registration and newsletter, selected separately; these options do not certify every checkout, password-reset or review integration. The listed fallback shows a checkbox on the next attempt after a low score and needs a separate pair of fallback keys. Check that your installed release offers it and that the customer can complete that next attempt.

Worked example: registration is protected, but fake accounts continue

Suppose the standalone account form rejects a missing token, but new junk accounts still appear. Trace a sample creation to its actual route. A custom checkout may submit guest or account details through another endpoint, while an importer or integration may create customers without using the public registration form. Confirm the intended behaviour of that route rather than raising the score threshold on a different form.

For contact spam, make the same distinction between a message created through the shop form and spam sent directly to your mailbox. A form challenge cannot intercept direct email. Once you identify the route, repeat both a valid submission and a refusal test there, checking the resulting customer, message or mail queue.

Test refusal, outages and legitimate customers

Run the following matrix on staging for every intended form and each supported route. Use test accounts and mail sinks, and verify the side effects as well as the visible response.

Test with a keyboard, screen reader, mobile connection and privacy tools. Retain form input where safe and provide a useful contact route, such as mypresta.rocks support for problems with its modules.

Tune scoring from your own action-level score distribution, abuse and legitimate completion rates. A threshold such as 0.5 is a trial value, not a universal safe setting. Do not assume that a particular browser, VPN or typing speed explains a low score.

Measure provider requests and transferred assets in a browser before choosing loading rules. Global loading can add work to pages without a protected form; conditional loading must still cover footer forms, modals and AJAX-inserted forms. No fixed JavaScript payload or conversion improvement applies to every configuration.

Monitor submitted forms, server-side refusals, false positives, spam outcomes and order completion over comparable periods. Separate form views, attempts, accepted submissions and unwanted results where your reporting supports them, and note campaigns or other changes in customer mix. A decrease or increase in spam does not alone prove the integration is correct. If provider checks pass but the accepted messages are still unwanted, review the content and submission pattern; a verified challenge is not a guarantee of a useful enquiry.

Use proportionate visitor restrictions and retention

An IP restriction targets a network address, not a person. Offices, universities, carrier networks, VPNs and proxies may serve unrelated customers. One abusive visitor may change address. Browser metadata is neither unique identification nor proof that accounts belong to one person.

Use the narrowest suitable action, expiry and address range. An exact address is narrower than 203.0.113.0/24; a wildcard or arbitrary address span can affect many visitors. Check the integration's IPv6 support before assuming its IPv4 matching rules apply.

A checkout restriction can include cart routes, while an authentication restriction can cover account, identity and password pages. Custom checkout and payment routes may behave differently. Test blocked and allowed users end to end and keep reviewed operational access for your team and monitoring.

Confirm the installed visitor module and schema before querying mprvc_* tables. For product-specific metadata, restriction, field and expiry settings, use the Customer Extra Info (IP Ban) help page; ban expiry deactivates a restriction and does not itself erase the record.

Document the purpose, reason, reviewer and retention period. Collect only what you need and distinguish optional fields from data always recorded by the integration. Remove obsolete information through a deliberate retention process, keeping incident evidence where required.

Country outside your delivery area does not automatically justify denying website access. EU rules constrain nationality- and residence-based restrictions and redirection; apply lawful, proportionate security measures and review existing orders and contractual duties. See Regulation (EU) 2018/302.

Worked example: an office shares the address you want to block

If repeated fake registrations come from an address also used by a legitimate business customer, compare the creation times and request paths before acting. Prefer a rule on the abused registration action over a full-store restriction where the integration permits it. Check what an authentication-scope rule actually covers: it may also stop that customer's sign-in or password recovery. Test an allowed colleague's journey as well as the unwanted request, set a review time and tell support how to report a mistaken refusal.

Maintenance access is a different control

The IP allowlist under Shop Parameters > General > Maintenance permits listed visitors to access a shop in maintenance mode. It is not a denylist for removing an offender from an otherwise open storefront. Use the control whose scope matches the action you intend to restrict.

Consent and provider privacy

CNIL distinguishes security-only CAPTCHA operations from operations that also serve additional purposes requiring consent. When consent is required, refusal must not create a security bypass: provide an alternative or complementary control that does not need that consent. A provider switch alone does not resolve data-protection and international-transfer duties. Follow the CNIL CAPTCHA guidance, question 17.

A hook called displayGDPRConsent can be a widget placement point. It does not by its name establish consent gating. Check script requests before consent, after refusal and after withdrawal, and test the server path too.

Handle empty carts and review the result

A category GET does not automatically persist a cart for every visitor. Native add-to-cart processing checks products and quantities first. Valid cart-add processing, a module or another session flow can create a cart; a later failure may leave it empty. Anonymous or empty carts alone do not prove bot activity or lost sales.

Correlate cart creation times with requests and identify the component that saves them. Traffic controls can reduce the requests they intercept, but they neither guarantee that cart growth stops nor remove existing records.

Use backups and age-limited, dependency-aware cleanup. Preserve order-linked carts, legitimate recoverable baskets, customisations, associated files and required incident records. Hiding confirmed noise from operational views is separate from deleting it.

Review limits after changes to URLs, themes, payment modules or traffic. Confirm that known crawlers, monitoring, payment callbacks, customers behind shared networks and accessibility tools still work. Watch rejected requests, false positives, response times and rendering capacity together.

Historical crawler figures are context, not a capacity forecast. Cloudflare measured aggregate search/AI crawler growth of 18% from May 2024 to May 2025, with an April 2025 peak 32% above May 2024. In its crawler breakdown, Googlebot requests rose 96% and its share moved from about 30% to 50%; GPTBot requests rose 305%, from 2.2% to 7.7% share. ClaudeBot fell 46% and Bytespider fell 85%; PerplexityBot's share rose from below 0.01% to 0.2%. The aggregate series was not a continuous rise. See the dated Cloudflare crawler analysis. Size your controls from your own current traffic.

Keep this work alongside updates, strong back-office authentication and monitoring. Use the security guide for the wider checklist and the breach-response guide if you suspect an intrusion.

Launch a reversible change and hand it over

1. Record the baseline. Save the affected routes, current settings and evidence of the problem. Agree what improvement should look like and which customer or integration failures require reversal.
2. Change a defined scope. Rehearse the relevant tests on staging and retain the previous configuration. Avoid changing the edge rule, CAPTCHA threshold and visitor restrictions together, which makes a refusal harder to attribute.
3. Check the production differences. Confirm live hostnames, provider keys, proxy trust, origin restrictions and available edge-plan features before the planned switch.
4. Run the narrow live trial. Use controlled customer journeys and provider-supported callback checks. Inspect the actual response and side effect; a green homepage does not prove checkout, sign-in or webhooks still work.
5. Review both outcomes. Compare remaining origin work and unwanted submissions with legitimate completions and support reports. If a valid journey fails, reverse the responsible change and investigate the recorded request.
6. Leave an operating record. Save the final scope, exceptions, reviewer, review date and reversal instructions. Make sure another authorised person can reach the control panel if the usual administrator is blocked or absent.

What to ask your developer or agency

• Which component receives each affected request, and what evidence links it to the problem?
• Where is the original client address trusted, and can an incoming header change the logged or blocked address?
• Which routes and side effects were tested on our installed theme, checkout and module releases, including direct submissions and provider failure?
• Which automated clients and shared-network customers were checked, and what load remains outside the rule?
• Who can reverse the change, where are the redacted results, and which future route or integration changes require another test?

Questions owners ask

My host recommends a bigger server. Should I agree?

Ask for evidence of the bottleneck and the requests causing it. Additional capacity may be justified for legitimate demand, but compare the remaining workload after a scoped traffic trial. A larger server alone leaves unwanted routes available.

Why does a customer fail only on their phone?

Ask for the time, affected page and visible error without collecting passwords or tokens. Trace that attempt through the edge, server and form integration, then reproduce the journey with the relevant mobile browser and connection. Changing every protection setting before identifying the refusing layer can hide the cause.

Can we test the protection by flooding the live checkout?

Use an agreed, bounded test plan on an isolated environment. Confirm who controls the test, which limits stop it and how orders, emails and payments stay isolated. Production validation should use the controlled journeys agreed with your host and integration providers.

Does a successful CAPTCHA mean an order is safe to fulfil?

No. It verifies the configured form challenge, not ownership of an account, payment legitimacy or delivery risk. Keep the order and payment review required for your business before releasing goods.