Production reality check
Your AI app passed the demo. Did it pass an attacker?
Security review is not asking the agent whether the code looks secure. It is tracing who can do what, with which data, across every trust boundary.
01
What happened?
Generated applications often assemble familiar components correctly in isolation while missing system-level policy: server-only secrets reach the client, record ownership is not enforced, or an admin action relies on hidden UI instead of authorization.
02
Why this happens
- Secrets or privileged keys are bundled into browser code or logs.
- Authentication exists, but object-level authorization is missing.
- Uploads, prompts, webhooks and redirects accept untrusted input without constraints.
- Dependencies, headers, cookies and production debug settings are not reviewed.
03
What you can check yourself
- Map users, roles, resources and allowed actions; test forbidden actions directly.
- Search source, build artifacts and history for secrets, then rotate exposed values.
- Validate input on the server and restrict outbound requests, uploads and redirects.
- Check dependency advisories, secure cookie flags, CSP and error handling.
NOT TECHNICAL
Think about what needs protecting — not how to protect it.
Security review sounds technical, but the starting question is one you already know the answer to.
- Customer data — names, emails, addresses, anything personal.
- Employee data and internal company information.
- Passwords and anything that proves who someone is.
- Payments — even through a payment provider, how it is wired up still matters.
- Who is allowed to see or change what — a customer should never be able to act like an admin.
Tell Shipvise or a reviewer what is on that list; they translate it into the specific technical checks — secrets, permissions, input handling — that keep it protected.
04
How to test the fix safely
Apply security fixes to a dedicated version, run automated checks, exercise abuse cases in staging and confirm logs do not leak sensitive values. Deploy with monitoring and a rollback decision prepared.
05
When you need a developer
Use a qualified reviewer when the app handles personal data, payments, privileged integrations or multi-tenant data. Shipvise can add AI or senior review to a controlled release workflow; it does not turn an untested app into a certified system.
FAQ
Questions people actually ask
Is vibe coding safe?
It can be used safely when scope, data sensitivity and controls are understood. Unreviewed generated code should not be trusted merely because the demo works.
Can an automated scan prove the app is secure?
No. Scans find classes of issues, but authorization, business logic and operational exposure require context and often manual testing.
What is the first security check?
Verify that no secret or privileged API key is sent to the browser, then test whether one user can access or change another user’s records.
What are the most common security problems in AI-built apps?
Missing authorization checks are the big one — an app that confirms who a user is but not what they are allowed to see or change. Exposed API keys or secrets in client-side code, and default access rules left wide open, are close behind.
Can an AI-generated app leak database credentials or API keys?
Yes, this happens often. Generated code sometimes puts a key meant for the server into code that ships to the browser, where anyone can read it. Search your codebase and build output for secrets before launch, and rotate anything that was exposed.
Is the default Supabase or Firebase configuration secure enough on its own?
Not usually. Both give you authentication out of the box, but you still need to configure access rules yourself so users can only reach their own data — the default setup is a starting point, not a finished security model.