How to fix passive scan only on PrestaShop

Steps for PrestaShop

1. PrestaShop is self-hosted — set up a staging copy on a private subdomain, keeping it IP-restricted so bots and customers cannot reach it.
2. Copy your production database (anonymised — remove real customer data) to staging and point staging's configuration to it.
3. Install OWASP ZAP locally. Target your staging URL, configure an authenticated session using a test-customer account to cover the cart, checkout, and My Account areas.
4. Run Active Scan, focusing on custom modules in /modules/ and any overrides in /override/ — these are the most frequent sources of custom vulnerabilities in PrestaShop.
5. Remediate High/Critical findings, then redeploy the patched code to staging and re-scan before promoting to production.
6. Use PrestaShop's built-in Security page (Admin → Advanced Parameters → Security) to review additional hardening options alongside DAST results.

What is passive scan only?

Automated security scanners that check your live store passively — inspecting HTTP headers, TLS certificates, cookies, and DNS records — can only see what is publicly visible without logging in or submitting forms. They cannot detect deeper vulnerabilities like SQL injection, broken authentication, insecure API endpoints, or business-logic flaws. Dynamic Application Security Testing (DAST) tools, such as OWASP ZAP, actively probe a running copy of your application the way a real attacker would — sending crafted requests, testing login flows, and fuzzing inputs — to surface vulnerabilities a passive scan will never find. Running DAST against a staging environment (never your live store) gives you a much more complete security picture before code reaches customers.

Security misconfigurations and undetected vulnerabilities are the #5 risk on the OWASP Top Ten and are a leading cause of data breaches in ecommerce — exposing customer payment data, personal information, and admin credentials. A breach can result in PCI-DSS non-compliance fines, chargebacks, loss of payment-processor accounts, and severe reputational damage that directly destroys revenue. Relying solely on passive header checks leaves entire attack surfaces — checkout flows, account login, coupon logic, admin APIs — completely untested. Adding even a basic DAST scan to your pre-release checklist dramatically reduces the chance of shipping a critical vulnerability to production.

See the complete Passive scan only guide for every platform and the full background.