How to fix passive scan only on Magento Open Source

Steps for Magento Open Source

1. Magento Open Source is self-hosted, so you have full control. Create a staging server (identical PHP version, same extensions, same Magento version) on a private or IP-restricted URL.
2. Disable cron jobs and order-notification emails on staging to prevent test data polluting real operations.
3. Download OWASP ZAP and configure it to target your staging URL. Create a Magento test-customer account and use ZAP's 'Form-Based Authentication' to enable authenticated scanning of cart, checkout, and account pages.
4. Run Active Scan; prioritise findings in custom modules under app/code/ and any third-party extensions in vendor/. Check REST API endpoints at /rest/V1/ and GraphQL at /graphql.
5. Remediate findings — common Magento issues include insecure deserialization, SQL injection in custom modules, and admin-panel exposure. Re-run ZAP to confirm fixes.
6. Add ZAP to your deployment pipeline: use the ZAP Docker image (ghcr.io/zaproxy/zaproxy) in your CI/CD (e.g. GitHub Actions) to automate scans on every release.

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.