How to fix passive scan only on Webflow

Steps for Webflow

1. Duplicate your Webflow project as a staging copy: in the Webflow Dashboard, click the three-dot menu on your project → Duplicate.
2. Publish the duplicate to its free webflow.io subdomain (not your custom domain) — it will not be indexed by default.
3. 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.
4. For Webflow Commerce stores, specifically test the checkout flow and any custom-code embeds (Project Settings → Custom Code) for XSS.
5. 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.
6. 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.

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.

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.

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