Vibe Coding Security Checklist

AI-generated code can be useful and still be unsafe. Models optimise for a plausible completion of the request; they do not carry accountability for your users, credentials, or production systems. Use this checklist before a vibe-coded project handles real data or real consequences.

Secrets and configuration

No API keys, passwords, tokens, private URLs, or sample credentials are committed.
Secret files are excluded from version control and build artifacts.
Browser code receives only values safe to expose publicly.
Logs and error responses redact credentials and personal data.
Deployment secrets use the host’s protected secret store.

Search both the current tree and commit history. Removing a secret from the latest file does not invalidate an exposed credential; rotate it.

Authentication and authorization

Every protected server action checks the authenticated identity.
Authorization is enforced on the server, not merely by hiding UI controls.
Object identifiers cannot be changed to access another user’s records.
Session cookies use appropriate secure, HTTP-only, and same-site settings.
Password reset, invitation, and account-recovery flows expire and cannot be replayed.

Ask the agent to explain the difference between “logged in” and “allowed to perform this action” for every write endpoint.

Input and output

Untrusted input is validated against an explicit schema.
Database access uses parameterized queries or safe framework APIs.
User content is escaped for the context where it appears.
Uploaded files have type, size, storage, and access restrictions.
Redirect destinations and outbound URLs cannot be freely abused.

Validation should reject unexpected input rather than attempting to clean every possible malicious value.

Data and privacy

Collect only the data the feature needs.
Document where data is stored, who can access it, and when it is deleted.
Do not send private source code, customer data, or secrets to a model unless the provider, account, and user agreement permit it.
Backups, analytics, error tracking, and model prompts are included in the data-flow review.
Destructive operations require confirmation, narrow permissions, and recovery where feasible.

Dependencies and generated setup

Review newly introduced packages and why each is needed.
Use supported versions and commit a lockfile.
Run the ecosystem’s vulnerability audit, while recognising that a clean audit does not prove safe application logic.
Inspect install, build, and post-install scripts before running unfamiliar dependencies.
Remove abandoned experiments and unused packages.

External actions and agents

An agent with shell, browser, repository, cloud, or email access can produce side effects beyond code generation.

Start with the minimum tool permissions.
Separate read-only research from writes.
Preview outbound messages, deployments, and deletions.
Do not let untrusted page or repository content silently redefine the task.
Keep an audit trail for consequential actions.

Verification before release

Test both permitted and forbidden user paths.
Run static checks, tests, and a production build.
Exercise failure behavior when dependencies time out or return malformed data.
Review security headers and production configuration.
Use a separate test environment for migrations and external integrations.
Obtain experienced human review for authentication, payments, sensitive data, or high-impact automation.

After release

Monitor authentication failures, permission errors, unexpected outbound traffic, and elevated exception rates. Keep dependencies updated, establish a contact for vulnerability reports, and maintain a rollback path.