CF GarageThe PrestaShop specificity: a session cookie from the very first visit
As soon as a visitor lands, PrestaShop sets a session cookie (cart cookie, session ID). Cloudflare does not cache responses to cookie-carrying requests by default, so without dedicated configuration the hit ratio stays near zero and the proxy adds almost nothing. Conversely, a global "Cache Everything" would break carts by serving pages across visitors. The right configuration sits in between.
The recommended configuration playbook
- SSL/TLS mode Full (strict). A valid origin certificate, never Flexible: this is the setting that prevents the infinite HTTPS redirect loop and guarantees order data is encrypted end to end.
- Targeted Cache Rules for the catalog. Cache the static theme and catalog paths (
/themes/,/js/,/css/,/img/,/c/for category images) with a long Edge TTL, plus product and category pages without session state. Never include/cart,/order,/my-account,/authentication, or module URLs. - Exempt payment callbacks from challenges. Payment modules (Stripe, PayPal, systempay, Mollie...) call URLs like
/module/<module>/validation. These automated requests must be exempted from Bot Fight Mode and challenge-setting WAF rules, otherwise payments confirmed at the PSP are never validated in the store. Use a targeted WAF exception on those paths, and check Security > Events after any failed payment. - Protect the back office. The
/adminXXXpath (renaming the default path is PrestaShop hygiene rule number one) should get hardened treatment: country or IP-list restriction, a challenge on every request, cache exclusion. Nearly every PrestaShop compromise starts with brute force on the back office. - Restore real visitor IPs. Behind the proxy, PrestaShop sees Cloudflare IPs. Country geolocation, country-based sales restrictions, and security logs must read the
CF-Connecting-IPheader, otherwise geolocation places visitors in North America. Cloudflare provides the header natively; it is an application-level setting or a module configuration. - Turnstile on sensitive forms. The Cloudflare Turnstile widget replaces classic captchas on customer signup, contact, and account creation forms. For PrestaShop it integrates via a dedicated module or custom template work, with the attention point being the payment-callback exemption described above.
- Validate every step on a test environment. Any cache or security rule gets tested first on staging or a dedicated URL, with a full purchase path: add to cart, login, test payment, confirmation email received.
Mistakes that cost orders
- Global cache-everything: one customer's cart page shows another's cart, or a product page serves a stale version. On e-commerce the rule is: cache by explicit path, never "everything".
- WAF blocking payment callbacks: payments go through at the PSP but the store stays "pending": the automated validation requests were filtered as bots. The debugging reflex is to check Security > Events at the exact time of a failed payment.
- Undetected geolocation drift: if the store restricts sales by country and reads the raw IP, it can block legitimate customers or allow the wrong ones. Test it systematically after enabling the proxy.
- A back office open to the world: a PrestaShop back office reachable from everywhere behind a proxy with no specific rule concentrates all the brute force. A simple challenge on
/adminXXXremoves most of the noise. - Purging without targeting: purging the entire cache at every stock update collapses the hit ratio. Cache Rules by path plus targeted purges by URL keep the store fast through catalog updates.
Frequently asked questions
Can PrestaShop product pages be cached at Cloudflare?
Yes for the catalog, as long as session-state pages are excluded: cart, checkout, account, login. PrestaShop sets a cookie on the very first visit, so a reliable setup targets catalog paths explicitly with Cache Rules and excludes transactional paths, rather than a global cache-everything that would mix sessions.
Why do payments or webhooks fail behind Cloudflare?
Payment module callback URLs and webhook endpoints receive automated requests that the WAF and Bot Fight Mode may treat as suspicious. Exempt those paths from challenges in the security rules while keeping protection elsewhere, and check Security > Events whenever a payment gets stuck.
How do you protect the PrestaShop back office with Cloudflare?
Use the custom admin path as the rule criterion: country or IP-list restriction, a challenge on every request to that path, cache exclusion. Combined with renaming the admin path, it removes most of the brute force targeting PrestaShop.
Does PrestaShop geolocation become inaccurate behind Cloudflare?
Yes, if the application reads the connection IP: it sees Cloudflare data center IPs. PrestaShop must read the CF-Connecting-IP header for geolocation and country restrictions, otherwise geo rules apply to the proxies instead of the real customers.