PrestaShop Security Engine ships a focused set of PrestaShop-native protections — scanning, monitoring, request filtering, access hardening, and a security dashboard — without padding the list with features that do not exist.
What: Heuristic scans of store files for risky PHP patterns, obfuscation, and known dangerous tooling.
Why: Compromises often leave behind webshells or unexpected PHP in upload and module paths.
What you see: Scan results with severity, file paths, and guidance to review or remove suspicious files.
What: Baseline critical paths and detect unexpected file changes that may indicate tampering.
Why: Quiet edits to core, overrides, or modules are a common early signal of unauthorized access.
What you see: Integrity reports listing changed, added, or unexpected files against your baseline.
What: Inspect front-office input for SQL injection and XSS-style probes, log attacks, and temporarily lock abusive IPs.
Why: Automated probes hit public PrestaShop endpoints constantly; early blocks reduce noise and risk.
What you see: WAF activity in the dashboard, attack logs, and temporary IP locks when thresholds are hit.
What: Cross-check installed modules against Friends Of Presta advisories and known fixed versions.
Why: Outdated modules with public advisories are a frequent entry point for store takeovers.
What you see: Module risk findings with advisory context and upgrade targets where known.
What: Log back-office login attempts and lock IPs that hammer authentication.
Why: Credential stuffing against the admin login is routine on exposed PrestaShop stores.
What you see: Login attempt history, lockouts, and related events on the security dashboard.
What: TOTP 2FA for back-office employees to harden staff access.
Why: Passwords alone are not enough when employee accounts are phished or reused.
What you see: Per-employee 2FA setup and a second-factor step at back-office login when enabled.
What: Block or flag registrations and checkout emails from known disposable providers.
Why: Throwaway addresses fuel fake accounts, abuse, and noisy fraud patterns.
What you see: Configurable blocking behavior and related block/log entries when abuse is attempted.
What: Restrict or monitor traffic by country rules and Tor exit traffic where configured.
Why: Some stores only sell to specific regions; Tor exits are often used for probing and fraud.
What you see: Policy settings and blocked or logged requests according to your geo/Tor rules.
What: Create and manage security-related backup snapshots from the module workflow.
Why: A recoverable copy of critical state matters when you need to roll back after an incident.
What you see: Backup actions and status in the module UI so you can take a snapshot before major changes.
What: Centralized logging of blocked requests, login abuse, and related security events.
Why: Merchants need a clear trail to investigate spikes and confirm protections are working.
What you see: Filterable event history tied to WAF, login protection, and other monitored signals.
What: Apply HTTP security headers to harden browser-facing responses.
Why: Missing headers leave avoidable room for clickjacking and related client-side issues.
What you see: Configurable header options and confirmation they are applied on store responses.
What: Detect and reduce abusive or fake cart activity that wastes resources and pollutes analytics.
Why: Bot-driven cart spam is common on PrestaShop and can mask real conversion problems.
What you see: Protection settings and related signals when suspicious cart patterns are blocked.
What: One back-office dashboard with a security score, critical findings, and recent protection activity.
Why: Scattered tools make it hard to prioritize; merchants need a single operational view.
What you see: Score overview, critical threats, WAF/login feeds, integrity and vulnerability summaries, and configuration cues.
