Cors security

Skill ShieldNet-360/secure-vibe/dist/agent-skills/.agents/skills/cors-security

SecureVibe — prevention-first security for AI-written code. Signed SKILL.md knowledge that makes AI coding assistants write secure code at generation time, plus a deterministic CI gate. Offline · keyless · Ed25519-signed. By ShieldNet360.

Install

npx -y skills add ShieldNet-360/secure-vibe --skill cors-security

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Strict CORS configuration: no wildcard with credentials, allowlist-based origins, sensible preflight cache, minimal exposed headers — Applies to: when generating CORS middleware or framework config; when wiring API Gateway / Cloud Front / Nginx CORS headers; when reviewing a cross-origin browser-facing endpoint

SKILL.md

3.3 KB, as published. Nobody here has run it

CORS Security

Strict CORS configuration: no wildcard with credentials, allowlist-based origins, sensible preflight cache, minimal exposed headers

ALWAYS

Use an allowlist of origins, not *. Reflect the incoming Origin header only when it matches a known entry from configuration (or matches a precompiled regex of operator-controlled hostnames).
If responses include credentials (cookies, Authorization), set Access-Control-Allow-Credentials: true and ensure Access-Control-Allow-Origin is a single specific origin string — never *.
Include Vary: Origin on responses whose body depends on the request Origin, so caches don't serve one origin's response to another.
Restrict preflight Access-Control-Allow-Methods to the actual methods the endpoint accepts; restrict Access-Control-Allow-Headers to the actual headers consumed.
Set Access-Control-Max-Age to a sensible value (≤ 86400 in production) to amortize preflight latency without locking in a bad allowlist.
Maintain the allowlist in code (or in a config file checked into source), not derived from a database — so attackers can't add their origin by inserting a row.

NEVER

Set Access-Control-Allow-Origin: * together with Access-Control-Allow-Credentials: true. The Fetch spec forbids it for a reason — browsers will refuse the response, but the bigger problem is that an upstream proxy / cache may already have leaked it.
Reflect the Origin header without an allowlist check (Access-Control- Allow-Origin: <Origin> for every incoming origin). That's the same as * for credentials but with worse caching behavior.
Allow null as an Origin. null is what Chrome sends from sandboxed iframes, data: URIs, and file:// — none of which should have credentialed access to your API.
Allow arbitrary subdomains with a regex like .*\.example\.com$ without considering subdomain takeover. Pin specific subdomains; treat *.example.com as a deliberate decision tied to subdomain ownership controls.
Expose internal headers via Access-Control-Expose-Headers. Limit to the minimal set the frontend genuinely needs.
Use CORS as authorization. CORS is a browser policy; it does not stop server-to-server, curl, or non-browser clients. Authenticate the request properly.

KNOWN FALSE POSITIVES

Truly public, unauthenticated APIs (e.g., open data, marketing CDN endpoints) can legitimately use Access-Control-Allow-Origin: * without credentials.
Internal admin tools restricted to a private network can use a single fixed origin; the wildcard concern doesn't apply because there are no cross-origin callers.
A handful of integrations (Stripe.js, Plaid, Auth0) expect specific CORS headers — read each provider's CORS section before relaxing the baseline.