Secure Code Review for AI-Written Code

The agent loads secure-code-review, runs the pre-flight, and starts with the scanner:

$ node scan-code.mjs .
app\invoices\PayButton.tsx:9  HIGH  public-env-secret  CWE-200  Secret-looking variable behind a public env prefix
    headers: { Authorization: `Bearer ${process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY}` },
    fix: Public prefixes are inlined into the client bundle at build time. Rename without the prefix and read it only in server code.
app\invoices\actions.ts:6  MEDIUM  server-action-no-auth  CWE-862  Server Action deleteInvoice has no visible authentication or authorization check
    export async function deleteInvoice(id: string) {
    fix: Server Actions are public POST endpoints. Verify the session and the caller's right to this specific record inside the action (or in the data layer it calls), and validate arguments with a schema.

Scanned 9 files: 1 high, 1 medium, 0 low.

It builds for production and checks what actually ships to browsers:

$ node check-build-secrets.mjs --env .env.production
.next\static\chunks\442-02vu_mtss.js:1  HIGH  stripe-secret-key  CWE-798  Stripe live secret or restricted key sk_live_De...

Checked 11 files in .next\static: 1 high, 0 other.

Mapping the attack surface turns up what the line scanner cannot see: GET /api/invoices/[id] loads findUnique({ where: { id } }) with no session and no owner check. On a local instance an anonymous request returned another organization's invoice with status 200. The report lists three findings:

Critical live Stripe secret key in the client bundle (A02/CWE-798; rotate the key now),

High IDOR on invoices (A01/CWE-639, ASVS 8.2.2),

High unauthenticated Server Action deleting any invoice (A01/CWE-862, ASVS 8.2.1).

The fix follows access-control-review: one server-only data access layer that every caller goes through.

import 'server-only';
import { cache } from 'react';
import { cookies } from 'next/headers';
import { jwtVerify } from 'jose';
import { db } from '@/lib/db';

const secret = process.env.SESSION_SECRET;
if (!secret) throw new Error('SESSION_SECRET is not set');
const key = new TextEncoder().encode(secret);

export const verifySession = cache(async () => {
  const token = (await cookies()).get('__Host-session')?.value;
  if (!token) throw new AuthError(401);
  try {
    const { payload } = await jwtVerify(token, key, { algorithms: ['HS256'], issuer: 'app', audience: 'app' });
    return { userId: String(payload.sub), orgId: String(payload.org), role: payload.role === 'admin' ? 'admin' : 'member' };
  } catch {
    throw new AuthError(401);
  }
});

export class AuthError extends Error {
  constructor(public status: 401 | 403 | 404) { super(String(status)); }
}

export async function getInvoice(id: string) {
  const session = await verifySession();
  const row = await db.invoice.findFirst({ where: { id, orgId: session.orgId } });
  if (!row) throw new AuthError(404);
  return { id: row.id, number: row.number, totalCents: row.totalCents, status: row.status };
}

export async function deleteInvoice(id: string) {
  const session = await verifySession();
  if (session.role !== 'admin') throw new AuthError(403);
  const { count } = await db.invoice.deleteMany({ where: { id, orgId: session.orgId } });
  if (count === 0) throw new AuthError(404);
}

The Server Action becomes await verifySession(); const id = z.uuid().parse(rawId); await deleteInvoice(id);, the Route Handler maps AuthError to its status, and the Stripe call moves to an authenticated Route Handler that reads STRIPE_SECRET_KEY on the server. After the rebuild:

$ node scan-code.mjs .
Scanned 11 files: 0 high, 0 medium, 0 low.
$ node check-build-secrets.mjs --env .env.production
Checked 11 files in .next\static: 0 high, 0 other.
$ curl (no cookie)        /api/invoices/<id>  -> 401
$ curl (org B session)    /api/invoices/<id>  -> 404
$ curl (org A session)    /api/invoices/<id>  -> 200 {"id":"...","number":"INV-1","totalCents":1000,"status":"open"}
$ curl (no cookie) POST   /api/pay            -> 401

All output above is real, from a Next.js 16.4.0 production build with the pack's scripts. The agent then adds the three-case authorization test from verify-fixes.md for each protected operation and puts both scripts in CI.