Practical Security Checklist

Vibe Coding Security Checklist

38 security checks for your vibe-coded application. Review data access, secrets and authentication whenever your app changes.

Scan your deployed app

A live scan checks observable behavior. Source code and private settings need separate review.

Need a workflow? Read how to review app security with your AI coding tool.

Not sure what a live scan can prove? Read our live-scan versus source-review guide.

Total Checks

Critical Items

Database Securitycritical

Protect your data from unauthorized access

Row Level Security (RLS) enabled on Supabase tables in exposed schemas(CRITICAL)

Run: SELECT tablename FROM pg_tables WHERE schemaname = 'public' AND NOT rowsecurity;

RLS policies restrict access to the intended users and records(CRITICAL)

Create policies only for the operations your app allows, then test them with two users

Firebase Security Rules deployed (if using Firebase)(CRITICAL)

Rules should deny by default, allow only specific authenticated operations

Anonymous database access returns only intentionally public data(CRITICAL)

Test with a public client key and no user session. Check grants and policies, not just the HTTP status

Service role key only used on server-side, never in frontend(CRITICAL)

Search codebase for 'service_role' - should only be in server files

Secrets & Credentialscritical

Keep your API keys and passwords safe

Secret keys stay server-side and out of browser bundles(CRITICAL)

Supabase anon/publishable and Stripe publishable keys can be public. Service-role, secret and provider billing keys cannot

.env files added to .gitignore(CRITICAL)

Verify .env, .env.local, .env.production are all in .gitignore

No secrets in git history(CRITICAL)

Run: git log -p | grep -i 'sk-\|password\|secret\|api_key'

Production secrets set in hosting platform, not local files

Check Vercel/Netlify/Railway dashboard for environment variables

Any previously exposed keys have been rotated(CRITICAL)

If keys were ever in git, consider them compromised and rotate

Authenticationcritical

Secure user access to your application

Authentication checked on server-side for all protected routes(CRITICAL)

Every API route should verify session before returning data

Email verification enabled for new signups

Check auth provider settings - users should confirm email before full access

Password requirements enforced (min 12 chars, complexity)

Test signup with weak passwords like '123456' - should be rejected

Session timeout configured appropriately

Default is often too long - consider 1 hour for sensitive apps

Logout properly clears session and redirects

Test that logged-out users can't access protected pages

OAuth and password-reset redirects allow only intended destinations(CRITICAL)

Review provider configuration and server-side redirect validation. Do not trust a return URL supplied by the browser

Session storage matches your authentication architecture

Use Secure and appropriate SameSite settings for cookies, and HttpOnly where supported. Review XSS exposure for browser-accessible tokens

API Securityhigh

Protect your API endpoints

All data endpoints verify user owns the requested resource(CRITICAL)

GET /api/orders/:id should check order.userId === session.user.id

Input validation on all API endpoints(CRITICAL)

Use Zod or similar to validate request body, params, query

Rate limiting configured for public endpoints

Prevent brute force attacks on login, signup, password reset

Error messages don't leak sensitive information

Return generic errors to client, log details server-side

CORS matches which browser clients should read each endpoint

A wildcard can be appropriate for public data. Restrict credentialed access, and enforce authorization on the server regardless of CORS

File uploads enforce ownership, size and permitted content types(CRITICAL)

Validate on the server and restrict storage access. A browser file picker is not an access control

Untrusted text is safely rendered and database queries are parameterized(CRITICAL)

Review raw HTML rendering and SQL construction. Use test fixtures to verify handling of unexpected input

Security Headershigh

Configure HTTP security headers

Strict-Transport-Security header enabled

Enforces HTTPS connections

X-Content-Type-Options: nosniff enabled

Prevents MIME type sniffing attacks

X-Frame-Options set to DENY or SAMEORIGIN

Prevents clickjacking attacks

Content-Security-Policy configured

Prevents XSS by controlling script sources

Referrer-Policy configured

Controls information sent to other sites

Code Qualitymedium

General security hygiene

Dependencies updated, no known vulnerabilities

Run: npm audit or yarn audit

No sensitive data logged to console

Search for console.log with user data, tokens, passwords

Public source maps do not reveal secrets or unintended source code

Review what the build publishes. Source maps alone are not proof of a security vulnerability

Error boundaries prevent crash information leakage

Production errors should show generic message, not stack trace

Security findings and incomplete coverage have been reviewed(CRITICAL)

Investigate evidence, fix confirmed issues and retest. Zero findings is not proof that the whole app is secure

Deploymenthigh

Verify the environment your users actually reach

HTTPS works on every public hostname(CRITICAL)

Check HTTP redirects, certificate validity and mixed-content requests

Private configuration and debug output are not public(CRITICAL)

Review deployed files for .env, backups and logs. Return generic errors rather than production stack traces

Production and test credentials are correctly scoped(CRITICAL)

Verify hosting environment variables and rebuild when a browser bundle contains a secret. A variable name does not make a value private

Security checks run after relevant changes

Repeat tests when auth, database policies, dependencies or integrations change. Keep evidence of the result

Add a live scan to your security review

Check your deployed app for observable data exposure, leaked secrets and missing protections. Review the evidence alongside your code and user-role tests.

Run your first scan free

Frequently Asked Questions

How do I use this security checklist?

Work through each section and record evidence for each applicable check. Treat the priority labels as starting points, not a substitute for your app's risk assessment. Combine a live scan with code, configuration and user-role tests.

How should I prioritize issues in an existing app?

Investigate exposed secrets, unintended data access and missing server-side authorization first. Consider the sensitivity of the data and the evidence for each issue. Do not assume that a lower-priority label makes a finding safe to ignore.

How often should I review this checklist?

Review before every production deployment, especially after adding new features or database tables. AI tools can introduce new vulnerabilities with each code generation. Make security review part of your deployment process.

Can vas check all these items automatically?

No. VAS checks reachable deployed pages, scripts and endpoints for observable issues such as exposed secrets, data access and missing browser protections. Git history, private source code, provider settings and complete role permissions require separate review. Read checks alone do not verify write permissions.

What's the most commonly missed item on this checklist?

Supabase table authorization. A table with RLS disabled and broad grants can expose data. RLS enabled with no applicable policy denies access by default, but overly broad policies can still expose private rows. Test grants and policies with two users.

Related Security Resources

Best Practices Guide Common Vulnerabilities Security Risks Startup Security Checklist

Last updated: January 16, 2026