You can build and launch a web app faster than ever. A prompt, a few iterations, a database connection, an authentication provider, and suddenly there is a real product on the internet.
That speed is exciting. It also creates a problem: an app can look complete before its security assumptions have been tested.
A missing authorization check, an exposed secret, an open database rule, or a forgotten test endpoint may not appear during a normal product review. The app works. The UI looks polished. The problem only becomes visible when someone looks at it from the outside—or when a real user reaches something they should not.
This is why we built VibeScan: a first-pass security check for the small app you just built with AI.
First, understand what you are trying to protect
Before opening a scanner, write down the parts of the app that would matter if they were exposed or changed:
- Which data belongs to which user?
- Which routes are public, authenticated, or admin-only?
- Which actions can create, change, or delete data?
- Which third-party services can access your app?
- Which secrets must never reach the browser?
This is a small threat-modeling exercise, not a compliance project. It gives you a reference point for deciding whether a finding is real and how serious it is.
The OWASP Top 10:2025 puts broken access control, security misconfiguration, software supply-chain failures, authentication failures, and injection among the core risks developers should understand. It is a useful starting map, not a complete test plan.
1. Test authentication and authorization separately
Authentication asks, “Who are you?” Authorization asks, “Are you allowed to do this?” A user can be correctly signed in and still be able to read another user’s data if the server does not check ownership or permissions.
Test the important actions with at least two accounts. Try changing an identifier in a request. Try opening a record created by another account. Try accessing an admin route as a normal user. These checks are especially important when an AI coding tool has generated similar routes quickly.
2. Search for secrets before they become public
API keys, database URLs, signing secrets, and service-role credentials should not be committed to a repository or bundled into browser code. A secret that has already reached a public repository or client bundle should be rotated, not merely renamed.
The OWASP Secrets Management Cheat Sheet covers the wider lifecycle: creation, storage, use, rotation, revocation, and monitoring. The practical version for a small app is simple: keep secrets server-side, use environment variables correctly, scan history as well as the current files, and rotate anything that may have been exposed.
3. Review database rules and object ownership
Database policies are often where a working prototype becomes a dangerous production app. Check whether a client can read or write rows directly, whether row-level security is enabled where it should be, and whether a service-role key can be reached through a user-controlled path.
Do not stop at “the database requires a login.” The important question is whether the logged-in user can access only the records and actions they are supposed to access.
4. Check dependencies and generated configuration
AI-generated code frequently arrives with a package list, deployment file, Docker image, or infrastructure configuration that was copied from a working example. Review the versions, lockfiles, build scripts, and permissions around deployment.
OWASP’s 2025 guidance expands the older vulnerable-components category into software supply-chain failures, which includes risks across the dependency and build ecosystem. Run dependency and secret checks as part of the normal development process, not once at the end.
5. Look at the live app, not only the repository
A repository review cannot tell you everything about the deployed application. Check the public URL for security headers, cookie flags, CORS behavior, exposed paths, debug output, unexpected endpoints, and configuration that changed during deployment.
The OWASP Web Security Testing Guide is a useful reference for understanding the difference between design review, code review, system testing, and production monitoring. A practical small-team workflow uses several of these layers without pretending that one automated scan covers them all.
6. Make the check repeatable
Security is not a launch-day checkbox. Every meaningful change to authentication, payments, database access, webhooks, or deployment configuration is a reason to repeat the baseline check.
That is the role VibeScan is designed to play. You can scan a live website or connect a GitHub repository, review findings in plain language, fix what is valid, and scan again. The service is intentionally a first-pass check—not a professional penetration test or a guarantee that an app is secure. Read the VibeScan documentation for the current scope and authorization model.
A practical pre-launch sequence
- List the sensitive data and high-impact actions in the app.
- Test authorization with more than one account.
- Scan the repository for secrets, dependencies, and risky patterns.
- Scan the live deployment for exposed paths and unsafe configuration.
- Fix the high-confidence findings first.
- Run the checks again and record what remains outside scope.
The best outcome is not a perfect-looking score. It is a clear understanding of what was tested, what was found, what was fixed, and what still needs a deeper review.
Have an AI-built app already in production?
Run a first security check with VibeScan →Further reading
- OWASP Top 10:2025 — a current awareness document for major web application risks.
- OWASP Secrets Management Cheat Sheet — practical guidance for handling sensitive values.
- OWASP Web Security Testing Guide — a broader testing methodology and reference.
- Stack Overflow 2025 AI survey — current developer sentiment and usage context for AI tools.
At MakeLabs, we build focused products for real problems. Read more about building apps solo, or see what we are building.