AI can write a convincing screen before anyone has checked what happens behind it. Before you share a vibe coded app, review the data it collects, the permissions it grants, and the code that handles requests. This checklist is a starting point for a small project. An app with sensitive data or high impact decisions needs a qualified security review.
Look for secrets and private data
Search the project for API keys, passwords, private tokens, and sample credentials. Put secrets in the deployment environment rather than browser code or a public repository, and rotate anything that was exposed during experimentation. Check that logs and error messages do not reveal account details or private records.
Use test data while developing. Decide what information the app really needs, where it is stored, who can read it, how long it stays there, and how a person can remove it. Do not assume that a generated database schema has the right privacy rules simply because the app loads.
- Remove real credentials from files, commit history, screenshots, and browser bundles.
- Collect only the information the feature needs.
- Check database rules and server permissions with a second account.
- Make error messages useful without disclosing private details.
Check input, access, and dependencies
Test unexpected input such as blank fields, very long text, unusual characters, and a request from someone who is not signed in. Confirm the server checks permissions for every action. Hiding a button in the interface is not access control if a person can still call the underlying route.
Ask why every new dependency is present and whether it is maintained. Run the project’s security and dependency checks when available. Review commands the agent wants to run, especially commands that install software, delete files, expose a local server, or change production data.
Treat repository content as untrusted input
AI agents read files, logs, issue descriptions, and sometimes web pages. Any of those can contain instructions that are irrelevant or malicious. A project file that tells an agent to reveal credentials is still just untrusted project content. Keep secrets out of the model context and review proposed commands and edits before approving them.
The same caution applies to generated code. Ask the agent to explain security sensitive changes, run tests, and show the diff. A test result is helpful evidence, not a guarantee that the design is safe.
- Read the full diff before accepting security sensitive changes.
- Run tests and static analysis, then inspect the cases they do not cover.
- Verify authentication and permissions from the server side.
- Have another developer review high risk features before release.
Keep a human release checklist
Write down who will respond if the app breaks, how you will restore data, and how to roll back a bad release. Check the production environment separately from the development setup. Remove test accounts and sample data, confirm HTTPS, and make sure monitoring does not expose private content.
For a practice project, this review can be short. For a product used by customers, the security checklist should match the harm a failure could cause. OWASP’s secure coding guidance for AI generated code is a useful reference, but it does not replace a review of your own product and deployment.
A prompt to adapt
Review this project for security risks before release. Do not change files. Identify exposed secrets, unsafe data handling, missing server side authorization, risky dependencies, and commands that could affect production. For each finding, cite the file and explain how I can verify it. Mark uncertain findings clearly.