Passive scan only
Moderate effortSet up regular active security testing (DAST) on a staging copy of your store to catch vulnerabilities that passive header/cookie/TLS scans cannot find.
What it is
Passive security scans — like the checks run on your HTTP headers, TLS certificate, cookies, and email DNS records — are a great first step, but they can only see what your store broadcasts to any visitor. They cannot test whether your login form is vulnerable to brute-force attacks, whether your checkout accepts malicious input, or whether an authenticated user can access another customer's data. Active security testing (called DAST — Dynamic Application Security Testing) actually interacts with your live or staging site the way a real attacker would, probing for those deeper vulnerabilities. Tools like OWASP ZAP (free) or commercial equivalents send crafted requests to your store and report weaknesses that a passive scan will never find.
Why it matters
A security breach on an ecommerce store can expose customer payment data, personal information, and order history — leading to regulatory fines (GDPR, PCI DSS), chargebacks, loss of payment processor access, and permanent damage to customer trust. Many of the most damaging attack types — SQL injection, cross-site scripting (XSS), broken authentication, insecure direct object references — are invisible to passive scanning but are caught routinely by DAST tools. Running active tests before each release means you find and fix vulnerabilities before attackers do, protecting your revenue, your customers, and your brand reputation. Skipping this step is one of the top reasons stores appear in breach reports despite having "green" passive security scores.
How to fix it
- Create a dedicated staging environment that is an accurate copy of your production store but is not publicly accessible (password-protect or IP-restrict it).
- Download and install OWASP ZAP (free, cross-platform) or choose a commercial DAST tool, then point it at your staging URL — never run active scans against your live production store.
- Configure the scanner with a test account (crawler credentials) so it can reach authenticated pages like checkout, account dashboard, and order history.
- Run a full active scan and review the report, prioritising findings rated High or Critical — common issues include XSS, SQL injection, insecure session handling, and exposed admin endpoints.
- Remediate flagged vulnerabilities (work with your developer or platform support), re-scan to confirm fixes, then promote the release to production.
- Schedule active DAST scans as a recurring step in your release process — at minimum before every significant code change or plugin/app update.
Fix it on your platform
Pick your platform for the exact steps.
How to fix passive scan only on Shopify
- Shopify hosts the production environment; you cannot self-host a true staging server, but you can use a separate Shopify development store (free via Partner account) as your staging target.
- In your Shopify Partner Dashboard → Stores → 'Add store' → 'Development store' — populate it with your current theme and a realistic product/order dataset.
- Password-protect the development store: Online Store → Preferences → Password protection → Enable password.
- Point OWASP ZAP at the development store URL. In ZAP: Quick Start → Automated Scan → enter the development store URL, add your test-account credentials under 'Context → Authentication'.
- Run the active scan, review findings, then apply fixes in the development store theme or via app settings before pushing theme changes to production with 'Publish'.
- Repeat before every theme update, new app install, or custom Liquid/JavaScript change.
How to fix passive scan only on WooCommerce
- Create a staging environment using your host's built-in staging tool (e.g., WP Engine, Kinsta, SiteGround all offer one-click staging) or use the free 'WP Staging' plugin: Plugins → Add New → search 'WP Staging' → Install & Activate → WP Staging → 'Create new staging site'.
- Ensure the staging site is not indexed (Settings → Reading → 'Discourage search engines') and is either password-protected at the server level or accessible only from your IP.
- Install OWASP ZAP on your local machine (download from zaproxy.org). Launch ZAP → Automated Scan → enter your staging URL.
- Add a 'Context' in ZAP with your WooCommerce test-account login so the scanner can reach the cart, checkout, and My Account pages.
- Run the active scan, note High/Critical findings, then fix them in staging (theme files via Appearance → Theme File Editor, plugin settings, or .htaccess via Plugins → File Manager).
- After fixes pass re-scan, sync or deploy staging to production using your host's push-to-live feature or WP Staging Pro's push function.
How to fix passive scan only on BigCommerce
- BigCommerce does not provide a native staging environment on standard plans; request a sandbox store through BigCommerce Support or use a Partner sandbox account.
- Populate the sandbox with your current theme (Storefront → Themes → Export from production, then import to sandbox) and realistic product data.
- Ensure the sandbox store is not indexed and restrict access: Store Setup → Store Settings → there is no built-in password gate, so request your sandbox URL remain unlisted or add basic-auth via a custom Nginx/Cloudflare rule in front of it.
- Run OWASP ZAP against the sandbox URL: Quick Start → Automated Scan → URL, and configure form-based authentication under Contexts so ZAP can scan authenticated checkout flows.
- Remediate any High/Critical findings by editing your Stencil theme locally (stencil CLI) or adjusting settings in the control panel, then re-scan.
- Deploy fixed theme to production via Storefront → Themes → Upload and apply.
How to fix passive scan only on Adobe Commerce (Magento)
- Adobe Commerce has native staging built in (Content → Staging & Preview on Commerce Cloud) — clone your environment using the CLI: 'magento-cloud environment:branch staging main'.
- On Magento Open Source, set up a staging server by cloning the codebase and database to a separate vhost or subdomain, then restrict access with .htaccess Basic Auth or an IP allowlist.
- Set the staging base URL: Stores → Configuration → General → Web → Base URLs → update to the staging domain.
- Run OWASP ZAP: Automated Scan → enter staging URL, configure script-based or form-based authentication under Contexts to reach the Magento admin panel and customer account areas.
- Review ZAP's Active Scan results; common Magento findings include exposed /admin path (change via Stores → Config → Advanced → Admin → Admin Base URL), outdated extensions, and session misconfigurations.
- Apply fixes (extension updates via Composer, config hardening via app/etc/env.php or admin panel), re-scan, then deploy to production with 'magento-cloud environment:merge' or your CI/CD pipeline.
How to fix passive scan only on Wix
- Wix does not offer a server-level staging environment; use the built-in 'Dev Mode' preview or duplicate your site: Site → Duplicate Site from the dashboard to create a test copy.
- On the duplicate site, keep it unpublished (it will have a wix.com subdomain that is not indexed).
- Because Wix is a fully managed SaaS platform, deep server-level DAST is limited — focus on scanning your published site's externally accessible endpoints (login, contact forms, Wix Stores checkout) using OWASP ZAP in passive/spider mode against the duplicate's preview URL.
- For any custom Velo (Wix Code) backend functions, review them manually against the OWASP Cheat Sheet for input validation and authentication.
- Report significant findings to Wix Support or disable vulnerable third-party apps from Add Apps → Manage Apps.
- Keep all Wix apps updated; most security fixes on the core platform are handled automatically by Wix.
How to fix passive scan only on Squarespace
- Squarespace is a fully managed SaaS platform with no self-hosted staging; create a free trial store as a staging proxy: squarespace.com → Get Started → use the same template.
- On the trial site, use Settings → Permissions → set Site Visibility to 'Password Protected' to prevent public indexing.
- Run OWASP ZAP in Spider/Passive mode against the trial URL to inventory pages and identify any exposed sensitive endpoints or missing security headers (Squarespace controls headers centrally).
- Active injection testing on Squarespace core is not applicable (Squarespace manages the backend); focus DAST efforts on any custom JavaScript injected via Settings → Advanced → Code Injection.
- Review all custom code blocks and third-party embed scripts for XSS risks — remove or sanitise any that accept user input.
- Report infrastructure-level findings to Squarespace Support; keep all Squarespace Extensions updated via the Extensions marketplace.
How to fix passive scan only on Webflow
- Duplicate your Webflow project as a staging copy: in the Webflow Dashboard, click the three-dot menu on your project → Duplicate.
- Publish the duplicate to its free webflow.io subdomain (not your custom domain) — it will not be indexed by default.
- Run OWASP ZAP → Automated Scan against the webflow.io staging URL, adding authentication context if you use Webflow's built-in Memberships or a third-party auth integration.
- For Webflow Commerce stores, specifically test the checkout flow and any custom-code embeds (Project Settings → Custom Code) for XSS.
- Fix vulnerabilities in the duplicate project's Designer or Custom Code settings, verify with re-scan, then replicate the same changes in your production project and re-publish.
- Check Webflow's security headers via Project Settings → Hosting — Webflow manages most headers centrally, but custom headers can be added via reverse proxy (e.g., Cloudflare) if needed.
Does your site have this issue?
Run a free SEOLZ scan 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?
Passive security scans — like the checks run on your HTTP headers, TLS certificate, cookies, and email DNS records — are a great first step, but they can only see what your store broadcasts to any visitor. They cannot test whether your login form is vulnerable to brute-force attacks, whether your checkout accepts malicious input, or whether an authenticated user can access another customer's data. Active security testing (called DAST — Dynamic Application Security Testing) actually interacts with your live or staging site the way a real attacker would, probing for those deeper vulnerabilities. Tools like OWASP ZAP (free) or commercial equivalents send crafted requests to your store and report weaknesses that a passive scan will never find.
Why does passive scan only matter?
A security breach on an ecommerce store can expose customer payment data, personal information, and order history — leading to regulatory fines (GDPR, PCI DSS), chargebacks, loss of payment processor access, and permanent damage to customer trust. Many of the most damaging attack types — SQL injection, cross-site scripting (XSS), broken authentication, insecure direct object references — are invisible to passive scanning but are caught routinely by DAST tools. Running active tests before each release means you find and fix vulnerabilities before attackers do, protecting your revenue, your customers, and your brand reputation. Skipping this step is one of the top reasons stores appear in breach reports despite having "green" passive security scores.
How do I fix passive scan only?
Set up regular active security testing (DAST) on a staging copy of your store to catch vulnerabilities that passive header/cookie/TLS scans cannot find.
Authoritative references
- OWASP Top Ten — OWASP
- OWASP Cheat Sheet Series — OWASP
- Secure Headers Project — OWASP
- Website security — MDN