Authentication security checklist for vibe-coded apps

AI builders reliably produce a login screen, because that is the visible part. The parts that are easy to skip are the ones that do the real work: enforcing access in the backend, scoping each query to the current user, expiring sessions, and locking down admin actions. The demo still works with those half-done, so the gaps ship.

Two definitions used throughout this page. Authentication confirms who a user is, usually through login. Authorization controls what that authenticated user is allowed to do or see. Most real-world account problems are authorization failures, not authentication failures.

Work through each item before launch. The best test is to use your app as a logged-out visitor and as a second, low-privilege account.

• Sensitive pages redirect or block when opened logged out, not just hide content.

• One user cannot read or change another user's data by changing an ID.

• Admin pages and admin actions are restricted to admins, enforced on the server.

• Sessions expire or can be revoked; logging out actually ends the session.

• Password reset links are single-use, time-limited, and do not reveal whether an email exists.

• APIs behind the UI check authentication and authorization, not just the page.

• You tested access boundaries as a second low-privilege user before launch.

Login and signup are where accounts are created and entered, so small mistakes here scale to every user. The goal is to confirm identity without leaking information or leaving obvious openings.

• Error messages do not reveal whether an email is registered.

• There is some protection against automated guessing, such as rate limiting.

• Email verification is required where account trust matters.

• Third-party login (Google, GitHub, etc.) is configured for your real domains only.

A session is what keeps a user logged in between requests. If sessions never expire or cookies are loosely scoped, a leaked or stolen session can be reused.

• Session cookies use Secure, HttpOnly, and a sensible SameSite setting.

• Sessions expire after a reasonable period and can be revoked.

• Logging out invalidates the session, not just the local UI state.

• Session identifiers are not exposed in URLs or logs.

Password reset is a common target because it can hand over an account if it is weak. The reset link is effectively a temporary key, so it must be hard to guess and short-lived.

• Reset links are single-use and expire quickly.

• The reset response does not confirm whether an email address exists.

• Completing a reset invalidates existing sessions where appropriate.

• Reset and verification emails point only to your real domain.

This is the boundary that fast-built apps miss most often. Authentication gets a user through the front door; authorization decides which rooms they can enter. A logged-in user should still only ever reach their own data.

• Every request that reads or changes data checks who is asking.

• Access is enforced in the backend and database, not only hidden in the UI.

• Changing an ID in a URL or request does not expose another user's records.

• Default-deny: new endpoints are closed until access is explicitly granted.

If your data lives in Supabase, the Supabase RLS checklist covers enforcing per-user access at the database level.

Admin features concentrate risk: one unprotected admin route can expose every user's data at once. Role-based access means permissions are tied to a user's role (admin, member, viewer) and checked on every sensitive action.

• Admin routes are not reachable by a regular logged-in user.

• Admin actions (delete, edit, export, impersonate) re-check the user's role server-side.

• Roles cannot be changed by the user themselves through the API.

• Debug or impersonation tools are disabled or restricted in production.

GuardMint runs a public, non-invasive scan without logging in. It cannot prove your auth is correct, but it can flag external signals worth a closer look. Our methodology explains the approach.

• Whether a sensitive-looking route responds without any login at all.

• Weak cookie flags on responses it can see.

• Overly permissive CORS on public endpoints.

• Error responses that leak internal details about your auth stack.

Authentication correctness lives behind the login wall and in your code, where an external scan cannot reach. The items below need you, a second test account, or a developer.

• Whether per-user data access is correctly enforced in the backend.

• Whether admin and role checks run on every sensitive action.

• Whether sessions expire and password reset cannot be abused.

• Whether business logic behind login (billing, sharing, exports) is safe.

What is an authentication security checklist?

It is a pre-launch review of how your app handles login, sessions, password reset, and access control. For vibe-coded apps it focuses on the boundaries AI builders commonly get wrong: protecting pages but not the data behind them, missing per-user checks, and admin actions reachable by regular users.

What is the difference between authentication and authorization?

Authentication confirms who a user is, usually through login. Authorization controls what that authenticated user is allowed to do or see. An app can authenticate users correctly and still fail authorization — for example, by letting any logged-in user open another user's records.

Can GuardMint test whether my login works correctly?

No. GuardMint scans your public surface without logging in, so it cannot test flows that happen behind authentication, and it cannot prove your login, session, or access rules are implemented correctly. It can flag signals like a sensitive route loading without a login or missing protections on the responses it can see.

Why does authentication break so often in fast-built apps?

AI builders and no-code tools optimize for a working demo. They reliably render a login screen, but the harder parts — enforcing access in the backend, scoping data per user, expiring sessions, and locking down admin actions — are easy to leave half-done because the demo still works.

How do I check authorization without a developer?

Create a second test account with no special privileges. While logged in as that user, try to open another user's data by changing an ID in the URL, and try to reach admin pages directly. If anything loads that should not, you have an authorization gap. For anything you are unsure about, ask a developer to review the backend rules.

Is a login screen enough to protect a page?

No. A login screen is only the front door. Real protection comes from the server and database enforcing who can read or change each piece of data. A page can render for anyone with the link even when it shows a login form, and an API behind it can still be callable directly.