AI coding tools compress the distance between an idea and a working interface. They do not remove the security work between a private prototype and a public service. That gap becomes more important when the app adds accounts, stores personal data, accepts files, calls paid APIs, connects to a database, or takes money.

This is a risk-based orientation, not a penetration test or a guarantee. The controls are mapped to primary guidance from the OWASP Application Security Verification Standard, the OWASP Top 10, and CISA's Secure by Design principles.

A happy-path demo answers “Can the intended action work?” Security asks different questions: “Who else can trigger it?”, “What can they read or change?”, “What happens with hostile input?”, “What does failure cost?”, and “How will the owner know?”

Generated code often combines frameworks, packages, copied patterns, and configuration that look plausible together. A successful build does not demonstrate correct authorization, tenant isolation, rate limiting, secret handling, safe file processing, dependency maintenance, or recoverability. Those properties require explicit design and verification.

Authentication proves an identity. Authorization decides what that identity may do. Many damaging failures happen after login because the server trusts a project ID, user ID, organization ID, or role sent by the browser.

For every sensitive operation, verify on the server that the current user can access that specific record and perform that specific action. Test with two ordinary accounts. Create data as account A, then deliberately attempt to read, edit, export, or delete it as account B. Change identifiers in URLs and requests. Test administrative actions as a non-admin.

Do not publish detailed vulnerability evidence in a public project comment. Use a private reporting path and avoid accessing other people's data while verifying a concern.

Anything delivered to the browser must be treated as public. A variable name such as SECRET_KEY does not make a value secret if it is bundled into client JavaScript. Keep database administrator credentials, service-role keys, payment secrets, model-provider keys, and signing keys on the server. Scope each credential narrowly and rotate it after suspected exposure.

Classify data before collecting it. For each field, write down why it is needed, where it is stored, who can access it, how long it remains, how it can be exported or deleted, and what happens if it leaks. If you cannot answer those questions, the safest choice is often not to collect the field yet.

Logs deserve the same review. They should help diagnose operations without recording passwords, session tokens, API keys, full payment payloads, private prompts, or unnecessary personal content.

Think like a user who wants a different outcome from the one shown in the demo. Can they create thousands of expensive requests, upload an unexpected file, submit an enormous payload, enumerate private records, inject instructions into an AI workflow, or make the service send messages to arbitrary recipients?

Use limits at multiple layers: request size, file type and size, rate, concurrency, token or compute budget, daily account allowance, and downstream vendor spend. Timeouts and cancellation matter for slow operations. Queued work needs idempotency so a retry does not charge twice or repeat an irreversible action.

If the app uses a language model, separate trusted system instructions from untrusted user or retrieved content. Treat model output as untrusted data before it reaches a shell, database query, template, email, or external API. Human approval is appropriate for consequential actions.

Record the runtime version, package manager lockfile, build command, migration process, environment variables, and deployment owner. Remove packages and integrations you no longer use. Review automated update alerts, but do not merge dependency upgrades blindly: test the application and read material release notes.

Production and preview environments should not share powerful credentials or customer data by default. Database migrations need a backup and rollback decision. The app should fail closed when critical configuration is missing, with a useful server-side error rather than a blank page or exposed stack trace.

Secure defaults reduce the amount every user must understand. CISA's Secure by Design guidance places responsibility on product makers to make important protections available out of the box rather than shifting the whole burden to customers.

You cannot investigate what you cannot observe. At minimum, capture failed authentication patterns, authorization denials, administrative changes, unexpected error rates, background-job failures, and abnormal vendor usage. Alerts must reach a person who knows the first containment step.

Recovery evidence is stronger than “we have backups.” Restore a backup into a separate environment. Document the point-in-time you can recover to, how long restoration takes, which credentials must change after an incident, and who can pause deploys, disable an integration, or place the app in maintenance mode.

We grouped pre-release questions under five observable gates, then mapped them to OWASP ASVS verification areas, common OWASP Top 10 failure classes, and CISA's secure-by-design position. The article avoids exploit instructions, invented breach statistics, and claims that a tool or framework is secure by default.

Before exposing a higher-risk app, ask a qualified security reviewer to check the scope, terminology, and safe-testing approach. Treat project-specific screenshots and findings as private unless the owner has approved publication.

Do not ask “Is vibe coding safe?” as a single yes-or-no question. Ask whether this version, with this data, these users, these integrations, and these controls has enough verified evidence for its intended exposure. A private prototype, a small invitation-only beta, and a public paid service have different acceptable risk.

If the evidence is incomplete, reduce exposure: remove sensitive data, narrow permissions, cap usage, disable irreversible actions, invite fewer users, or bring in focused help. A smaller safe release teaches more than a broad launch built on assumptions.