The Pre-Deploy Security Checklist for Vibe-Coded Apps

This checklist is designed for the final hour before production, when teams need signal instead of noise.

01. Confirm server-only secrets stayed server-only

1. 01. Search for service_role, sk_live_, OPENAI_API_KEY, and internal admin tokens.
2. 02. Inspect environment variable exposure through NEXT_PUBLIC_ prefixes.
3. 03. Verify that client bundles do not reference internal endpoints protected only by obscurity.

One recurring AI-generated edge case is a helper that accidentally promotes a server secret into a client-safe constant:

export const supabaseAdmin = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY!,
);

The hallucination is not subtle. The model often invents a NEXT_PUBLIC_ prefix because the code “needs to run everywhere.”

02. Verify authorization at the mutation layer

Every write path should answer: who is allowed to do this, and where is that enforced?

1. 01. route handlers
2. 02. Server Actions
3. 03. RPC functions
4. 04. edge functions
5. 05. background jobs

Do not accept “the UI only shows this to admins” as authorization.

03. Check RLS, storage, and data exposure

1. 01. enable RLS on user tables
2. 02. validate policy conditions against auth.uid()
3. 03. confirm private buckets are not public
4. 04. review RPC functions for broad execution

JWT payloads are useful, but they are not a permission model by themselves.

04. [Component: DarkWireframeKey]

The DarkWireframeKey visual should show a release path flowing from commit to deploy, with red markers on secrets, server actions, storage buckets, and JWT validation. The article references those exact points because the checklist is meant to be run visually as well as textually.

05. Review client-side hydration and debugging output

Hydration leaks are easy to miss because they look like harmless convenience during development.

Check for:

1. 01. admin-only objects passed through serialized props
2. 02. debug payloads rendered into hidden DOM nodes
3. 03. config blobs exposing internal IDs or tokens
4. 04. user records sent to the browser unnecessarily

06. Confirm API and route behavior

1. 01. auth routes reject malformed tokens
2. 02. admin routes do not infer access from a UI role flag
3. 03. write endpoints validate ownership
4. 04. public APIs rate-limit or constrain abuse paths

07. Make the deploy observable

Before you ship, confirm you will know if the release fails securely:

1. 01. auth failures are logged
2. 02. billing errors are logged
3. 03. permission denials are visible
4. 04. important mutation paths emit useful identifiers

08. Final release decision

Do not ask, “Does the app work?”

Ask:

1. 01. did any privileged value reach the client?
2. 02. can one user access another user’s data?
3. 03. can a public route write or mutate unexpectedly?
4. 04. can we explain our authorization model in one paragraph?

If you cannot answer those cleanly, the deploy is not ready.