AI-assisted builders make it easy to connect authentication, databases, payments and external APIs. They also make it easy to accept generated security assumptions without testing them. The fastest useful response is not a vague request to “make the app secure.” It is a bounded verification pass tied to the product's real data and actions.

This checklist turns the risk map in Vibe Coding Security and Vibe Coding Security Risks into release evidence. It is a starting point for builders, not a substitute for a qualified review when the product handles sensitive data, money, regulated activity or high-impact decisions.

Write a one-page system map. Name the browser or mobile client, application server, database, authentication provider, storage, email, payment, analytics, AI models and other external APIs. Mark which components receive personal or confidential data and which can perform a paid, privileged or irreversible action.

Create two ordinary test users, one privileged test user if the product has roles, and a clean test environment that resembles production. Prepare one harmless record owned by each user. Store no real customer secrets in test fixtures.

For every check, capture four fields: test, evidence, result, and owner. “The AI said it fixed this” is not evidence. A request/response pair, screenshot, automated test, configuration view or recovery exercise is evidence.

Verify sign-up, sign-in, sign-out, password or magic-link recovery, and session expiry. Test expired and reused links. Confirm that an account disabled at the identity provider cannot keep using an old privileged session indefinitely.

Check whether sensitive changes require recent authentication. Email change, password change, payout details, API-key creation and organization ownership transfer deserve a stronger boundary than opening a normal page. Avoid leaking whether an email address exists through account-recovery messages.

If the product uses social login, verify the callback URLs and the account-linking behavior. A second provider with the same email must not unexpectedly take over an existing account.

Authentication answers who the user is. Authorization answers whether that user can perform this exact action on this exact object. Test the backend, not only hidden buttons.

Sign in as user A, create a record, then use user B to request the record's read, update and delete endpoints. Change identifiers in URLs, form payloads and API requests. Repeat the check for uploaded files, exports, comments, organization settings and background jobs.

OWASP's authorization guidance recommends denying access by default, validating permissions on every request and preferring ownership or attribute checks over fragile URL assumptions. Administrative screens need the same server-side enforcement as the visible product.

Search the repository and built client assets for API keys, private URLs and tokens. Review deployment variables and provider dashboards. Browser code can safely contain public identifiers designed for that use, but a service secret must stay in a trusted server boundary.

Verify that logs do not record passwords, session tokens, magic links, payment details, authorization headers or raw sensitive prompts. Rotate any credential that was committed, pasted into a public issue or exposed to the browser; deleting the line later does not make the old credential safe.

Give each integration the minimum scope it needs. Separate development and production credentials. Record the owner, purpose, storage location and rotation or revocation method for every production secret.

List each collected field and why the product needs it. Remove speculative data. Confirm transport encryption, storage location, retention, account deletion and backup behavior. If a user deletes an account, define what disappears immediately, what remains for legal or security reasons and what ages out of backups.

Test uploads by content, size and authorization rather than trusting the filename. Use generated storage names, safe content types and access-controlled delivery where files are private. For analytics and AI services, verify what data leaves the application and whether the user has been told accurately.

Database row-level policies can be valuable, but do not treat their existence as proof. Test the policies with the same multi-user scenarios as the application endpoints.

Inventory direct dependencies, lock the resolved versions and run the ecosystem's vulnerability checks. Investigate reachable, high-impact findings instead of treating the count as a quality score. Remove unused packages and generated experiments that expand the attack surface.

Require a readable diff for AI-generated changes. Security-sensitive code deserves human review: authentication callbacks, database policies, upload handling, payment webhooks, server actions and permission helpers. NIST's Secure Software Development Framework emphasizes protecting software, producing well-secured releases, responding to vulnerabilities and addressing their root causes. Those practices apply regardless of who wrote the first draft.

Identify actions an attacker can repeat cheaply while creating cost or harm: account creation, password reset, AI calls, email sends, file uploads, search, scraping, invitations and payment attempts. Add rate limits at the trusted boundary, not only a disabled button.

Set budget and usage alerts for paid APIs. Constrain model tools and external actions. Validate webhook signatures and make paid or state-changing handlers idempotent so retries do not duplicate an order, email or entitlement. Decide what happens when a provider is slow or unavailable.

Test abuse controls from more than one account and network context where practical. Make sure defensive errors do not disclose secrets or internal stack traces.

Define the events that require attention: repeated authorization failures, unusual sign-ups, payment webhook errors, elevated AI spend, background-job backlog, data export, role escalation and application error rate. Route alerts to a person who can act.

Backups matter only if restoration works. Perform a dated restore into a safe environment, verify critical records and record the recovery time. Write the minimum incident procedure: who can disable an integration, revoke keys, pause sign-ups, roll back a release, contact users and preserve evidence.

Security debt can remain at launch when it is understood and proportionate. Record the consequence, affected surface, compensating control, owner and review date. Unknown debt should not be silently relabeled as accepted risk.

We mapped common AI-built application boundaries to the stable OWASP ASVS 5.0 structure, OWASP authentication and authorization guidance, and NIST SP 800-218 on August 9, 2026. We selected checks a small product team can execute and evidence before release. The checklist deliberately emphasizes observable behavior over tool claims.

We did not test a specific reader's application or claim compliance with ASVS. For higher-risk use, ask a security reviewer to confirm the scope and phrasing. Products handling health, financial, child, biometric, or other sensitive data require additional legal, privacy, and domain-specific review.

Stop a release when a failure permits cross-user access, exposes a production secret, allows unauthorized money movement, corrupts critical data or leaves the owner unable to recover. For lower-consequence findings, create a dated remediation item and a temporary control rather than burying it in chat history.

Attach the completed evidence sheet to the project's release decision. If the boundary needs specialist review, browse the Heyviber developer directory and share the system map, failed checks and desired deliverable instead of asking for an undefined “security audit.”