Fix guide · high · csp_wildcard_script_src

CSP script-src includes a wildcard or full-protocol scheme

Why it matters

script-src 'self' https: looks restrictive but isn't — any HTTPS URL counts. *.cloudflare.com, *.googleusercontent.com, GitHub Gists, jsDelivr, anywhere an attacker can publish content matches.

The policy usually shows up because the developer wanted to allow scripts from a CDN and reached for the broadest match (https:) instead of pinning the specific domain (https://cdn.your-app.com). Sometimes it's defensive — they're afraid pinning will break a feature. But every week of script-src https: in production is a week where a CDN compromise anywhere on the public internet is your CDN compromise.

How to fix it

Replace the wildcard with a pinned allowlist:

# BEFORE
Content-Security-Policy: default-src 'self'; script-src 'self' https:

# AFTER
Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.your-app.com https://js.stripe.com

Identify what scripts your page actually loads:

# Open DevTools Console, paste:
performance.getEntriesByType('resource')
  .filter(e => e.initiatorType === 'script')
  .map(e => new URL(e.name).origin)

That's your allowlist. Pin each origin explicitly. If a third-party script loads other scripts (Stripe.js, Google Analytics), you may need to add their loaded origins too — check their docs for the canonical CSP recipe.

Full guide: /blog/csp-bypass-vibe-coded.

Did vibecheck flag this on your app?

If you reached this page from a vibecheck inspection report, the redacted match in your scan output is the exact string we found in your bundle. After applying the fix above, run the inspection again — the finding should clear.