PrestaShop Firewall: monitoring and blocking, e‑commerce rules, allowed IPs/URLs and compatibility

Purpose of this article

This guide explains how to use the application firewall provided by the Securantis module for PrestaShop (1.7 to 9). You will learn how to choose between observation and blocking modes, enable rules dedicated to online commerce (orders, payments, webhooks, AJAX), allow IPs and URLs, and verify compatibility and the “fail‑open” behavior to avoid any interruption of a production store.

Audience and prerequisites

• Securantis module installed and linked to your Securantis account.
• PrestaShop 1.7 to 9; PHP 7.2+ recommended by the vendor.
• Administrator access to the PrestaShop back office.
• Recent backup (files and database) before any configuration changes.

General behavior and principles

• Firewall modes: observation (logs only) and blocking (interrupting malicious requests). Always start in observation on an active store to measure false positives.
• E‑commerce rules: sets of signatures and heuristics designed to minimize blocking on sensitive actions (payment, order, cart, webhooks). These rules can be enabled separately.
• Allowlists: you can declare IPs or URLs exempted from filtering to ensure access for third‑party providers (payment gateway IPs, monitoring IPs) or certain internal endpoints.
• Fail‑open: in case of an internal module or infrastructure error, the fallback mode neutralizes blocking to keep the store available.

Recommended steps (gradual production deployment)

1. Switch to observation

• Enable the firewall in observation mode. Objective: collect real detections and identify false positives without impacting customers.
• Let it run for several days covering your activity peaks (e.g. weekday and weekend).

2. Review events and e‑commerce rules

• Examine the logs: prioritize detections on checkout flows, APIs and webhooks.
• Enable the “e‑commerce” or “store protection” rules if available: they reduce severity on critical operations while still flagging attacks.

3. Allowances (IP and URL)

• Allowed IP list: add the IP addresses of your providers (payment gateways, invoicing services, monitoring tools) so they bypass filtering.
• Allowed URL list: allow known endpoints (webhooks, internal API endpoints) if the firewall flags legitimate requests.
• Test each allowance in simulation (observation) before enabling blocking.

4. Progressive switching to blocking

• Enable blocking for a subset of non‑critical rules (e.g. general XSS signatures) for a few hours while observing incidents.
• If no customer impact is observed, extend blocking to critical rules while keeping e‑commerce rules more permissive if necessary.

5. Continuous supervision

• Schedule reports and alerts to monitor block rate, the most active rules and blocked IPs.
• Keep regular observation periods after major changes (module updates, promotions launch).

Careful settings and recommendations

• Do not immediately block signatures affecting payments or webhooks. Prefer an observation period and gradual actions.
• Prefer allowing an IP over globally disabling a rule: it is safer and more targeted.
• Document each change (who, when, why) so you can roll back quickly if needed.
• Enable the “fail‑open” mode or verify its presence: in case of module error, this prevents loss of sales.

Frequent errors and causes

• False positives on AJAX endpoints or webhooks: often caused by signatures that are too strict or JSON payloads not recognized.
• Blocking payment gateways: provider IPs not present in the allowlist.
• Loss of back office access for some employees: dynamic IP not allowed or a rule too restrictive on administrative pages.
• “Module not connected” alert or inability to verify the license: outbound network problems or license information not yet activated.

Step‑by‑step troubleshooting

1. If the store experiences customer blockings

• Immediately switch the firewall to observation or enable the fallback mode to restore access.
• Identify recent events: blocked URLs, source IPs, triggered rules.
• Urgently add legitimate IPs to the allowlist and test the affected flows.

2. If payments fail

• Check the logs to identify requests sent to the payment gateway and add the gateway IP to the allowed IPs.
• Confirm with the payment provider their list of IPs or domains if necessary.

3. If the back office is inaccessible for certain accounts

• Check if a rule targeting administrative pages is active; disable it temporarily or allow the concerned IP.
• Verify the presence of a third‑party back office plugin that modifies routes and generates unrecognized signatures.

4. If the module reports an update or license issue

• Check the server’s network connection to Securantis services and the license status in the customer area.
• If an update is proposed, schedule it outside peak activity and switch to observation after installation.

Precautions and best practices

• Do not automatically delete files reported as malicious: deletion or quarantine requires a human decision.
• Never share passwords by email or chat for support. If access is required for a paid intervention, it will be provided via the secure customer area after payment.
• Always test rule changes on a preproduction store if possible.
• Keep backups before any major firewall modification or module update.

Compatibility and limits

• The Securantis module for PrestaShop is designed for PrestaShop 1.7 to 9 and runs on PHP 7.2+. Do not install the module on unsupported versions.
• The firewall applies general rules for SQLi, XSS, sensitive paths and rate controls, but it does not guarantee to stop all attacks. Some third‑party tools or shop customizations may require specific exceptions.
• In atypical hosting environments (reverse proxy, CDN, X‑Forwarded‑For header configuration), adjust settings so the module reads the original IP correctly.

When to contact Securantis support

Contact support if:

• Persistent blockings that impact sales despite adding allowlists and switching to observation.
• Inconsistent behavior after a module or PrestaShop update.
• Doubts about detection of a critical file: you want help to analyze before any deletion or quarantine.
• You need a deeper intervention (audit or resolution by our technicians). Note that for interventions requiring access, credentials will be requested via the secure customer area after commercial agreement.

Expected outcome

By following this guide you should:

• Have an active firewall in observation and e‑commerce rules adjusted without service interruption.
• Gradually reduce false positives and, if desired, enable blocking for non‑critical signatures.
• Keep payments, webhooks and customer flows functional thanks to IP/URL allowlists and the fail‑open mode.

Annex — Quick points

• Always start in observation.
• Allow IPs from payment and monitoring providers.
• Preserve quarantine and deletion for human decision.
• Contact support for critical blockings or analysis of suspicious files.

Keywords : pare‑feu PrestaShop, WAF, règles e‑commerce, liste blanche IP, autorisation URL, fail‑open, PrestaShop 1.7–9, PHP 7.2+