> vibe coding security checklist

Vibe coding security checklist

A vibe coding security checklist should start with what a stranger can reach from the deployed URL: exposed files, source maps, security headers, CORS, cookies, secret-shaped client strings, and logged-out API responses. Then review the parts a public scan cannot prove: authorization rules, tenant isolation, payment entitlements, webhook signatures, and business logic.

Start scan See demo report

> scan map

What this scan should cover

Critical public checks

Run these before the app leaves private testing.

No .env, .git, backup, debug, or deployment metadata files are reachable
No public source maps for production JavaScript bundles
No secret-shaped strings in HTML, JavaScript, or network responses
No unauthenticated API route returns private JSON or user data

Browser and API controls

Confirm the deployed app has a safe public baseline.

HTTPS is enforced and cookies use Secure, HttpOnly, and SameSite where appropriate
CSP, frame protection, referrer policy, and permissions policy are intentional
CORS does not allow arbitrary origins with credentials
Verbose errors and stack traces do not leak implementation details

Manual owner review

Use test accounts and source context for what the outside cannot prove.

User A cannot read or modify User B records
Free users cannot unlock paid or admin features by changing requests
Webhook handlers verify signatures and reject replayed payloads
Database and storage rules match the real tenant and role model

> where vibecodeguard fits

Public-surface evidence before launch.

VibeCodeGuard covers the public-surface half of the checklist. Paste the staging or production URL, fix the ranked evidence, then use the remaining checklist items for code review, test-account checks, and payment or tenant logic.

Scan public URL

> limits

What a public scan cannot prove

A checklist is not a security certification.
A public scan cannot prove account-specific business rules or tenant isolation by itself.
Payment, admin, and webhook logic still need source-aware or account-aware review.

> sources

References used for this page

OWASP Top 10 ↗Primary reference for common web application risk categories.
OWASP Application Security Verification Standard ↗Primary reference for verification areas that require application context.
OWASP Web Security Testing Guide ↗Primary reference for practical web security testing methodology.
OWASP Secure Headers Project ↗Primary reference for browser security headers in the public-surface checklist.

> faq

Direct answers

What belongs on a vibe coding security checklist?

Include exposed files, source maps, leaked client-side secrets, headers, CORS, cookies, unauthenticated APIs, storage exposure, authorization, tenant isolation, payment entitlements, webhook verification, dependency hygiene, and a retest step after fixes.

What should I check first before sharing a vibe-coded app?

Start with the deployed URL. If a stranger can fetch private files, source maps, secret-shaped strings, or data-bearing APIs without logging in, that is a launch blocker before deeper review even starts.

Can I use only a checklist instead of a scanner?

Use both. A checklist keeps the launch review complete, while a scanner gives repeatable evidence for the public-surface items and makes it harder to miss a reachable file, header, or endpoint.