Passive scan only
Moderate effortComplement passive security scans with active Dynamic Application Security Testing (DAST) against a staging copy of your store before each release.
What it is
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.
Why it matters
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.
How to fix it
- Set up a staging environment that is a close replica of your production store — same code, same plugins/apps, same configuration — but isolated from real customer data and not publicly indexed.
- Choose a DAST tool appropriate for your skill level: OWASP ZAP (free, open-source, GUI and CLI modes) is the most accessible starting point; commercial alternatives include Burp Suite Pro and Beagle Security.
- Configure the DAST tool with your staging URL and, for authenticated scanning, supply a test account with known credentials so the tool can reach protected pages like checkout, account, and admin.
- Run an automated 'spider + active scan' against staging. Review the findings report, prioritising High and Critical severity issues — focus on injection flaws, authentication bypasses, sensitive data exposure, and insecure direct object references.
- Remediate findings in your codebase or platform configuration, re-run the scan to confirm fixes, then promote the release to production.
- Schedule DAST scans as a recurring step before every significant release or at least monthly, and store reports so you can demonstrate a security-testing programme to auditors or payment processors.
Fix it on your platform
Pick your platform for the exact steps.
How to fix passive scan only on Shopify
- Shopify's production infrastructure is managed by Shopify — you cannot run DAST against Shopify's shared servers. Focus active testing on any custom apps, custom storefronts (Hydrogen/Storefront API), or third-party integrations you own.
- For custom Shopify apps or Hydrogen storefronts: deploy a staging version to a separate Shopify development store or a staging server (e.g. Vercel preview URL).
- Point OWASP ZAP (downloadable from zaproxy.org) at your development-store or staging URL. Enable 'Ajax Spider' for JavaScript-rendered pages common in Headless/Hydrogen setups.
- In ZAP, add an 'HTTP Session' with a logged-in test-customer cookie to scan authenticated checkout and account flows.
- Review ZAP's Alerts panel; remediate High/Medium findings in your custom app code before submitting to the Shopify App Store or pushing to production.
- For the hosted Shopify theme layer, rely on Shopify's own security programme and focus your DAST budget on custom code you control.
How to fix passive scan only on WooCommerce
- Create a staging site using your host's staging tool (e.g. WP Engine, Kinsta, SiteGround all offer one-click staging) or duplicate the site manually to a subdomain (e.g. staging.yourstore.com).
- Block the staging site from search engines (WordPress Admin → Settings → Reading → 'Discourage search engines') and restrict access by IP or HTTP Basic Auth so DAST traffic stays private.
- Download and install OWASP ZAP on your local machine or a test server. Set the target to your staging URL.
- Configure an authenticated scan: in ZAP go to Tools → Options → Authentication, supply a WooCommerce test-customer login, and record the session so ZAP can scan the cart, checkout, and My Account pages.
- Run 'Active Scan'. Pay special attention to WooCommerce REST API endpoints (/wp-json/wc/v3/) and any custom plugins. Remediate findings before deploying to production.
- Consider adding a WordPress security plugin (e.g. Wordfence, Patchstack) to your production site for ongoing monitoring between DAST runs.
How to fix passive scan only on BigCommerce
- BigCommerce's core platform is managed infrastructure. Direct active scanning of BigCommerce's shared servers is prohibited by their ToS. Focus DAST on your custom theme JavaScript, custom widgets, and any external apps or APIs you own.
- For custom integrations or headless BigCommerce frontends, deploy a staging version to a separate environment (e.g. a BigCommerce sandbox store or a staging URL on Vercel/Netlify).
- Point OWASP ZAP at your staging/sandbox store URL. Use the Ajax Spider for Stencil theme pages that rely on client-side rendering.
- Supply a test-customer session cookie in ZAP to scan authenticated flows (cart, checkout, account).
- Remediate any High/Critical findings in your theme code or custom app before pushing to production.
- For the platform itself, monitor BigCommerce's security advisories and keep all installed apps updated via BigCommerce Admin → Apps → My Apps.
How to fix passive scan only on Adobe Commerce (Magento)
- Adobe Commerce (self-hosted or cloud) gives you full server access, making it the most straightforward platform for DAST. Set up a staging environment that mirrors production — same Magento version, same extensions, same configuration.
- Restrict staging access: configure your web server (Nginx/Apache) or CDN to whitelist only your IP for DAST traffic, and disable indexing via robots.txt on staging.
- Install OWASP ZAP on a local or CI machine. Set the target to your staging URL (e.g. https://staging.yourstore.com).
- Configure authenticated scanning: record a ZAP login script using a Magento test-customer account to allow ZAP to scan cart, checkout, customer account, and any custom REST/GraphQL API endpoints under /rest/ and /graphql.
- Run the Active Scan. Magento's common risk areas include custom modules, third-party extensions, and the Admin Panel URL — ensure the Admin is not on the default /admin path and is IP-restricted.
- Integrate ZAP CLI into your CI/CD pipeline (e.g. GitHub Actions, GitLab CI) so a DAST scan runs automatically against staging on every release branch before merge to production.
How to fix passive scan only on Wix
- Wix is a fully managed SaaS platform; you cannot run DAST against Wix's infrastructure directly. Active scanning of Wix's shared servers is not permitted.
- Focus your security testing on Wix Velo (custom JavaScript code), custom backends, and any external APIs or third-party services your Wix site calls.
- If you have a Velo backend or external API, deploy it to a separate staging/test environment and point OWASP ZAP at that endpoint.
- For Velo code, conduct code review using OWASP Cheat Sheet guidance for JavaScript/Node.js (input validation, output encoding, secrets management).
- Keep all Wix Apps updated via your Wix Dashboard → Add Apps → Manage Apps, as third-party Wix apps are a common vulnerability source.
- For deeper security testing needs, consider migrating business-critical custom logic to a self-hosted API service where DAST is fully permitted.
How to fix passive scan only on Squarespace
- Squarespace is fully managed SaaS infrastructure; running DAST scans against Squarespace's servers directly is not permitted and not actionable.
- Focus security efforts on any custom JavaScript injected via Settings → Advanced → Code Injection or via Custom CSS — review this code manually against OWASP guidelines for XSS and data exposure.
- Audit all third-party integrations and extensions in your Squarespace Extensions panel (Commerce → Extensions) — keep them updated and remove unused ones.
- If you use Squarespace's API or webhooks to connect external services, deploy a staging version of that external service and run OWASP ZAP against it.
- Ensure your custom domain has HTTPS enforced (Settings → Domains → SSL) and review cookie settings under Settings → Advanced.
- For stores requiring deeper security assurance, consider whether a self-hosted platform would give you the control needed to implement and evidence a full DAST programme.
How to fix passive scan only on Webflow
- Webflow is managed SaaS; you cannot run DAST against Webflow's hosting infrastructure. Direct active scanning is not permitted.
- Focus DAST on any custom code added via the Webflow Designer's Embed elements or Page Settings → Custom Code sections — extract this code and review it manually or run it in an isolated test harness.
- If your Webflow site connects to external APIs (e.g. a custom backend, Xano, or Make/Zapier flows), deploy a staging copy of that backend and scan it with OWASP ZAP.
- Audit third-party scripts loaded by your Webflow site (Designer → Pages → Page Settings → Before/After </body>) — remove any scripts not actively needed, as third-party JS is a primary attack vector.
- Ensure Webflow's built-in SSL is active (Webflow Dashboard → Hosting → SSL) and that form submissions do not expose sensitive data in Webflow's form notification emails.
- For ecommerce stores handling significant transaction volume, evaluate exporting to a self-hosted environment (Webflow export + custom hosting) where full DAST is possible.
How to fix passive scan only on Magento Open Source
- 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.
- Disable cron jobs and order-notification emails on staging to prevent test data polluting real operations.
- 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.
- 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.
- Remediate findings — common Magento issues include insecure deserialization, SQL injection in custom modules, and admin-panel exposure. Re-run ZAP to confirm fixes.
- 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.
How to fix passive scan only on PrestaShop
- PrestaShop is self-hosted — set up a staging copy on a private subdomain, keeping it IP-restricted so bots and customers cannot reach it.
- Copy your production database (anonymised — remove real customer data) to staging and point staging's configuration to it.
- 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.
- 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.
- Remediate High/Critical findings, then redeploy the patched code to staging and re-scan before promoting to production.
- Use PrestaShop's built-in Security page (Admin → Advanced Parameters → Security) to review additional hardening options alongside DAST results.
Does your site have this issue?
Run a free SEOLZ audit to find passive scan only — and every other issue — across your whole site in minutes.
Scan my site freeFrequently asked questions
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.
Why does passive scan only matter?
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.
How do I fix passive scan only?
Complement passive security scans with active Dynamic Application Security Testing (DAST) against a staging copy of your store before each release.
Authoritative references
- OWASP Top Ten — OWASP
- OWASP Cheat Sheet Series — OWASP
- Website security — MDN