How to fix passive scan only on BigCommerce

Steps for BigCommerce

1. 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.
2. 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).
3. Point OWASP ZAP at your staging/sandbox store URL. Use the Ajax Spider for Stencil theme pages that rely on client-side rendering.
4. Supply a test-customer session cookie in ZAP to scan authenticated flows (cart, checkout, account).
5. Remediate any High/Critical findings in your theme code or custom app before pushing to production.
6. For the platform itself, monitor BigCommerce's security advisories and keep all installed apps updated via BigCommerce Admin → Apps → My Apps.

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.