I built a security audit tool. Then I pointed it at my own site.

Description and use

The author identified and fixed a wildcard CORS header on his own site using a self‑hosted ZAP and ExploitDB stack, validating the fix with a fresh scan.

Problem

A wildcard CORS header (Access‑Control‑Allow‑Origin: *) was exposed on the author’s own domain, allowing any origin to access the site’s resources.

Outcome

The author discovered a critical CORS misconfiguration on his own site, corrected it by adjusting CDN settings, and validated the fix with a fresh scan, highlighting the importance of verifying audit results rather than relying on cached data.

Workflow

• 1. Run OWASP ZAP scan against the target URL.
• 2. Identify the Access‑Control‑Allow‑Origin: * header in the scan results.
• 3. Trace the header source to Vercel CDN default settings.
• 4. Update the CDN configuration to specify allowed origins only.
• 5. Generate a fresh URL to avoid ZAP cache and rerun the scan.
• 6. Verify that the new scan shows the corrected header and no wildcard.
• 7. Document the change and confirm no functional regressions.

Evidence

It came back with a wildcard CORS header.

Source

Scoping the header down to the actual allowed origins took minutes.

Source

ZAP caches session results. Rerun a scan against the same URL you just tested and you can get a clean read that has nothing to do with whether your fix actually worked.

Source