ShipReady Guide · Next.js Security

How to Add Auth to Your Next.js API Routes

Every API route you ship is a public URL. If a route can read data, write data, send email, or spend your OpenAI credits, anyone on the internet can call it — the login screen on your homepage doesn't stop them. Here's how to lock your routes down.

The 10-second test: is your route open?

Open a terminal — or better, a private/incognito browser window where you're not logged in — and call your own API route directly:

curl -i https://your-app.com/api/user/profile

If you get back 200 OK and real data, your route is unprotected. It doesn't matter that the button calling it only appears after login. Attackers, bots, and curious strangers don't use your UI — they call the URL. This is the single most common security hole in vibe-coded apps, because AI coding tools happily generate working routes and rarely add the auth check.

The bug: trusting the request instead of the session

Most unprotected routes look like this. Notice where the user ID comes from:

import { NextResponse } from "next/server";
import { db } from "@/lib/db";

export async function POST(req: Request) {
  const { userId, message } = await req.json();

  // Anyone can send ANY userId — no login required.
  await db.messages.create({ data: { userId, message } });

  return NextResponse.json({ ok: true });
}

Two problems in one: there's no check that the caller is logged in at all, and the route trusts a userId supplied by the caller. Even if you add a login page in front of this, an attacker can post messages as any user by changing one field. The fix follows one rule:

The three auth patterns (pick yours)

Which pattern you need depends on who calls the route. Human users in a browser → session auth. A machine, cron job, or external service → an API key or secret. Pick your stack below:

import { NextResponse } from "next/server";
import { auth } from "@/auth";
import { db } from "@/lib/db";

export async function POST(req: Request) {
  const session = await auth();

  if (!session?.user?.id) {
    return NextResponse.json(
      { error: "Unauthorized" },
      { status: 401 }
    );
  }

  const { message } = await req.json();

  // userId comes from the session — never from the request body.
  await db.messages.create({
    data: { userId: session.user.id, message },
  });

  return NextResponse.json({ ok: true });
}

import { NextResponse } from "next/server";
import { createClient } from "@/utils/supabase/server";

export async function POST(req: Request) {
  const supabase = await createClient();

  const {
    data: { user },
  } = await supabase.auth.getUser();

  if (!user) {
    return NextResponse.json(
      { error: "Unauthorized" },
      { status: 401 }
    );
  }

  const { message } = await req.json();

  // user.id comes from the verified session.
  const { error } = await supabase
    .from("messages")
    .insert({ user_id: user.id, message });

  if (error) {
    return NextResponse.json(
      { error: "Insert failed" },
      { status: 500 }
    );
  }

  return NextResponse.json({ ok: true });
}

import { NextResponse } from "next/server";
import { timingSafeEqual } from "node:crypto";

function isAuthorized(req: Request) {
  const header = req.headers.get("authorization");
  if (!header?.startsWith("Bearer ")) return false;

  const token = Buffer.from(header.slice(7));
  const secret = Buffer.from(process.env.API_SECRET ?? "");
  if (secret.length === 0) return false;

  // timingSafeEqual avoids leaking the secret via response timing.
  return (
    token.length === secret.length &&
    timingSafeEqual(token, secret)
  );
}

export async function POST(req: Request) {
  if (!isAuthorized(req)) {
    return NextResponse.json(
      { error: "Unauthorized" },
      { status: 401 }
    );
  }

  // …run the job
  return NextResponse.json({ ok: true });
}

Which routes need auth — and which don't

Not every route should demand a login. Webhooks would break, and public content doesn't need a gate. Use this as the rule of thumb:

Middleware: a gate, not a lock

It's tempting to protect everything in one file. Auth.js can wrap your routes in middleware so unauthenticated requests never reach the handler:

import { auth } from "@/auth";
import { NextResponse } from "next/server";

export default auth((req) => {
  if (!req.auth) {
    return NextResponse.json(
      { error: "Unauthorized" },
      { status: 401 }
    );
  }
  return NextResponse.next();
});

export const config = {
  matcher: ["/api/:path*"],
};

Use it — it catches the routes you forgot. But don't rely on it alone:

Middleware also can't do the ownership check ("is this your message?") — that logic belongs in the handler, next to the data.

Verify the fix

Don't trust that it works — test it the way an attacker would:

1. Logged out: run the curl test again. You want 401 Unauthorized, not data.
2. Logged in: use the app normally. The route should work exactly as before.
3. Wrong user: log in as a second account and try to fetch or modify the first account's record by ID. You want 403 or 404 — never the data.
4. Every method: repeat for POST, PUT, PATCH, and DELETE. Protecting GET and forgetting DELETE is a classic.

curl -i -X POST https://your-app.com/api/messages \
  -H "Content-Type: application/json" \
  -d '{"userId": "someone-else", "message": "hi"}'

# HTTP/1.1 401 Unauthorized
# {"error":"Unauthorized"}

Mistakes that leave routes open

• !Hiding the UI instead of checking auth. If the URL works in curl, the route is open — no matter what your frontend shows or hides.
• !Taking userId from the request. Body, query string, or a client-set header — all are attacker-controlled. Identity comes from the session.
• !Protecting GET, forgetting DELETE. Every exported method in the file needs the check. Extract it into a small helper if you repeat it.
• !Returning 200 with an error message. { ok: false } with a 200 status confuses clients and monitoring. Use 401 / 403 properly.
• !Middleware-only protection. Fine as a first gate, fatal as the only gate — see CVE-2025-29927 above.
• !Trusting getSession() in Supabase. It reads the cookie without re-validating. Use getUser() in route handlers.
• !Hardcoding the API secret. Secrets live in environment variables. If a secret ever shipped in client code or a git commit, rotate it — deletion isn't enough.
• !Skipping webhook signature checks. A webhook URL is public by design; the signature is the only proof the request really came from Stripe, GitHub, or whoever sent it.

FAQ