DEV Community: Anas Sheikh

Your Next.js Dates Are Wrong for Half Your Users (and the Hydration Warning Is Only the Start)

Anas Sheikh — Tue, 20 Oct 2026 10:28:47 +0000

You format a date in a component. It looks right on your laptop. Then a user in another country opens the page and either sees a console full of hydration errors, or worse, sees nothing wrong at all and reads the wrong time.

I live in a timezone that is five hours away from where most servers run, so this one finds me every time.

The Code That Looks Fine

// components/OrderDate.tsx
export function OrderDate({ date }: { date: string }) {
  return <p>Ordered on {new Date(date).toLocaleString()}</p>;
}

No hooks, no browser APIs, nothing that looks risky. It even works in next dev, because on your machine the server and the browser are the same computer.

Why It Breaks

In Next.js, this component runs twice: once on the server to produce the HTML, and again in the browser to hydrate it. toLocaleString() with no arguments uses the timezone and language of whatever machine runs it.

The server is often in UTC, with a default locale such as en-US.
Your user's browser might be in Karachi, with en-GB.

Server HTML:   Ordered on 10/20/2026, 10:15:00 AM
Browser render: Ordered on 20/10/2026, 15:15:00

React compares the two, finds that they differ, and logs a hydration error. In development, you see it. In production, React quietly tries to recover by re-rendering on the client, which costs time and can cause a visible flash.

Why It Is Hard to Catch

It never fails where you test. Same machine, same timezone, same locale: the two outputs are identical.
Many users never see an error. The page just shows one format for a split second and then another.
It often hides inside other pieces of data. Date.now(), Math.random(), new Date().getFullYear() and anything that reads window or localStorage can all produce a different value on the server and in the browser.

The Fix That Is Tempting, and Wrong

You will find this advice everywhere:

<p suppressHydrationWarning>
  Ordered on {new Date(date).toLocaleString()}
</p>

It does silence the warning. But per React's documentation, it only suppresses the warning on that one element and does not patch up mismatched text. The user can end up looking at the server's version of the time, which is in the wrong timezone.

You did not fix the bug, you removed the alarm for it.

Fix 1: Make the Output the Same on Both Sides

Pass an explicit locale and timezone, so the server and the browser calculate the same string:

export function OrderDate({ date }: { date: string }) {
  const text = new Date(date).toLocaleString('en-US', {
    timeZone: 'UTC',
    dateStyle: 'medium',
    timeStyle: 'short',
  });

  return <time dateTime={date}>{text} UTC</time>;
}

This is deterministic, so there is nothing to mismatch. It is the right choice for logs, admin tables and anything where showing UTC is acceptable. Label it as UTC so nobody reads it as local time.

Fix 2: Show the Local Time After the Page Loads

If users should see their own timezone, only compute it in the browser:

'use client';

import { useEffect, useState } from 'react';

export function LocalDate({ date }: { date: string }) {
  const [local, setLocal] = useState<string | null>(null);

  useEffect(() => {
    setLocal(
      new Date(date).toLocaleString(undefined, {
        dateStyle: 'medium',
        timeStyle: 'short',
      })
    );
  }, [date]);

  return (
    <time dateTime={date}>
      {local ?? new Date(date).toISOString().slice(0, 10)}
    </time>
  );
}

The first render, on the server and in the browser, shows a stable fallback (the ISO date). Right after hydration, useEffect runs only in the browser and swaps in the local time. Nothing mismatches, and the user ends up with the right value.

The cost is a brief change from the fallback to the local string. Keep the fallback short so the layout does not jump.

Fix 3: Store and Send Dates as ISO Strings

Whichever display option you pick, pass dates around as ISO strings (2026-10-20T10:15:00.000Z) and format them only at the edge, in one place. An ISO string is plain text, so it means the same thing on the server, in the browser and in your database.

Which One When

Situation	Fix
Admin tables, logs, reports	Fixed locale and `timeZone: 'UTC'`
Customer-facing times (orders, bookings, messages)	Format in the browser after mount
A date that never changes (blog post date)	Fixed locale and timezone, since the author's date is what matters

The Rule

Any value that depends on where the code runs, such as timezone, locale, the current time or a random number, will differ between the server and the browser. Either make it identical on both sides, or compute it only in the browser after hydration. Do not suppress the warning and hope.

Quick audit: search your project for toLocaleString(, toLocaleDateString(, Date.now() and Math.random() inside components that render on the server. Each one is either deterministic on purpose, or a mismatch that has not met a user in another timezone yet.

Hydration mistakes also slow pages down, because React has to redo work in the browser. I explain what that does to real-world speed scores in this plain-language guide to Core Web Vitals, and I keep every date in my Next.js templates formatted through one small helper so the server and the browser always agree.

Get the templates: https://pixelanas.gumroad.com

Which timezone bug has bitten you hardest? Drop it in the comments, especially if it only showed up in production.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

forEach Doesn't Wait for Your await: The Bug That Makes APIs Reply Before the Work Is Done

Anas Sheikh — Mon, 19 Oct 2026 12:33:52 +0000

Your endpoint sends 50 emails, marks 50 orders as shipped, and returns { success: true }.

In your tests, it works. In production, the response comes back in 8 milliseconds, half the orders are still pending, and one failed email crashed the whole Node process with an error nobody can trace to a request.

The culprit is usually one innocent line.

The Code That Looks Fine

app.post('/api/ship', async (req, res) => {
  const orders = await Order.find({ status: 'paid' });

  orders.forEach(async (order) => {
    await sendShippingEmail(order);
    await Order.updateOne({ _id: order._id }, { status: 'shipped' });
  });

  res.json({ success: true });
});

There is an await inside, so it must wait. It does not.

Why It Returns Early

forEach was written before promises existed. It calls your function for each item and ignores whatever the function returns. An async function returns a promise, and forEach throws that promise away without looking at it.

So the loop starts 50 async tasks, finishes in one tick, and moves on. The await inside each callback only pauses that callback, not the loop around it, and not your handler.

console.log('start');
[1, 2, 3].forEach(async (n) => {
  await new Promise((r) => setTimeout(r, 100));
  console.log('done', n);
});
console.log('end');

// start
// end
// done 1
// done 2
// done 3

end prints before any work finishes. That is your res.json().

Why It Is Hard to Catch

Fast tests hide it. With a local database and a mocked email service, the work finishes before your next assertion runs. It passes by luck.
The failure is somewhere else. The response says success, so nothing points back to this line.
Errors escape. If a callback throws, nobody is awaiting that promise, so there is no try/catch that can catch it. Since Node 15, an unhandled rejection crashes the process by default. One bad email address can take down the server, and the stack trace will not mention the request that caused it.

Fix 1: Need It Sequential? Use for...of

for (const order of orders) {
  await sendShippingEmail(order);
  await Order.updateOne({ _id: order._id }, { status: 'shipped' });
}

res.json({ success: true });

for...of is real control flow, so await pauses the whole loop. Errors land in your try/catch. Use this when order matters, or when you must not hit a rate-limited API in parallel.

Fix 2: Need It Fast? Promise.all With map

await Promise.all(
  orders.map(async (order) => {
    await sendShippingEmail(order);
    await Order.updateOne({ _id: order._id }, { status: 'shipped' });
  })
);

res.json({ success: true });

map returns the array of promises that forEach was throwing away, and Promise.all waits for all of them. Same callback, one different method.

Fix 3: Some Failures Are Acceptable? Use allSettled

Promise.all rejects as soon as one promise fails, but the other tasks keep running. You get an error back while half the work still completes in the background.

If you want every task to finish and then look at what failed:

const results = await Promise.allSettled(orders.map(shipOrder));

const failed = results
  .map((r, i) => ({ r, order: orders[i] }))
  .filter(({ r }) => r.status === 'rejected');

res.json({
  shipped: results.length - failed.length,
  failed: failed.map(({ order }) => order._id),
});

Now one bad email does not hide the 49 that worked, and the response tells the caller exactly what to retry.

Fix 4: Thousands of Items? Limit the Concurrency

Promise.all(items.map(...)) starts everything at once. With 10,000 items, that is 10,000 simultaneous database calls or HTTP requests, which can exhaust your connection pool or get you rate limited.

Process in batches:

async function inBatches(items, size, fn) {
  const results = [];
  for (let i = 0; i < items.length; i += size) {
    const batch = items.slice(i, i + size);
    results.push(...(await Promise.all(batch.map(fn))));
  }
  return results;
}

await inBatches(orders, 10, shipOrder);

Ten at a time is fast enough for most jobs and gentle on whatever is on the other end.

Same Trap in filter, some, every and reduce

forEach is not the only method that does not understand promises.

// Always keeps everything. A Promise is truthy.
const valid = users.filter(async (u) => await isActive(u));

The callback returns a promise for every user, and a promise object is always truthy, so nothing is ever filtered out. some and every have the same problem and return true immediately.

// Resolve first, then filter
const flags = await Promise.all(users.map(isActive));
const valid = users.filter((_, i) => flags[i]);

The Rule

Array methods like forEach, filter, some and every do not await. If an async function sits inside one, the work is detached from your request. Use for...of to run steps in order, and Promise.all or Promise.allSettled with map to run them together.

Quick audit: search your project for .forEach(async. In a route handler, a job or a script that exits when it finishes, each hit is either a bug or a race that has not lost yet.

I use this pattern in the bulk operations behind my Next.js and MongoDB templates on pixelanas.com, where seeding, imports and batch updates must finish before the response goes out.

Get the templates: https://pixelanas.gumroad.com

How many .forEach(async do you find in your codebase? Drop the number in the comments, and tell me if one of them turned out to be a real bug.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Your TypeScript Is Lying to You, and These 5 Places Hide Real Bugs

Anas Sheikh — Sun, 18 Oct 2026 12:29:32 +0000

TypeScript's most dangerous keyword is two letters long.

as does not convert anything. It does not check anything. It tells the compiler "trust me", and the compiler does. If you are wrong, the error moves from your editor to your users.

Here are five places I keep finding it in real codebases, each one compiling cleanly and each one a crash waiting for the right input.

1. Casting an API Response

const res = await fetch('/api/users/1');
const user = (await res.json()) as User;

console.log(user.profile.avatarUrl);

res.json() returns Promise<any>. Casting any to User is the compiler equivalent of a handshake agreement. If the backend renames a field, makes profile optional, or returns an error object with a 200 status, this line still compiles and the crash happens three functions later with a message that has nothing to do with the cause.

What to write instead: validate the data at the boundary.

import { z } from 'zod';

const UserSchema = z.object({
  id: z.string(),
  email: z.string().email(),
  profile: z.object({ avatarUrl: z.string().url().nullable() }),
});

type User = z.infer<typeof UserSchema>;

const user = UserSchema.parse(await res.json());

Now the type is derived from a check that actually ran. If the shape is wrong, you get a clear error at the exact line where bad data entered your app.

2. The Non-Null Assertion on Environment Variables

const client = new MongoClient(process.env.DATABASE_URL!);

process.env.X is typed string | undefined, which is honest. The ! deletes the undefined from the type and nothing else. When the variable is missing in a new environment, you get a confusing failure from deep inside a library instead of "DATABASE_URL is missing".

function requireEnv(name: string): string {
  const value = process.env[name];
  if (!value) throw new Error(`Missing environment variable: ${name}`);
  return value;
}

const client = new MongoClient(requireEnv('DATABASE_URL'));

The app now fails at startup, with the variable name in the message. That is the cheapest place to find out.

3. The Non-Null Assertion on `find()`

const user = users.find((u) => u.id === id)!;
sendEmail(user.email);

find returns undefined when nothing matches, and "nothing matches" is exactly the case your tests forgot. The ! makes the compiler stop warning you about the one scenario worth warning about.

const user = users.find((u) => u.id === id);
if (!user) throw new Error(`User ${id} not found`);

sendEmail(user.email);

After the check, TypeScript narrows user to a real object on its own. No assertion required.

4. Casting Object.keys

type Settings = { theme: string; lang: string };

function logSettings(s: Settings) {
  (Object.keys(s) as (keyof Settings)[]).forEach((k) => {
    console.log(s[k].toUpperCase());
  });
}

const fromApi = { theme: 'dark', lang: 'en', retries: 3 };
logSettings(fromApi);

This compiles. TypeScript types are structural, so an object with extra properties is still a valid Settings when it arrives through a variable. Object.keys returns plain string[] for exactly this reason, and the cast to keyof Settings overrides that protection. At runtime retries is a number, and toUpperCase is not a function.

const SETTING_KEYS = ['theme', 'lang'] as const;

function logSettings(s: Settings) {
  SETTING_KEYS.forEach((k) => console.log(s[k].toUpperCase()));
}

Iterate over a list of keys you control, not over whatever the object happens to contain.

5. Casting the Caught Error

try {
  await saveProfile(data);
} catch (e) {
  toast((e as Error).message);
}

In JavaScript you can throw anything: a string, a number, undefined, a plain object. Libraries do it. With strict on, TypeScript types e as unknown to keep you honest, and as Error is the line that undoes it. If something throws a string, .message is undefined and your toast says "undefined".

catch (e) {
  const message = e instanceof Error ? e.message : 'Something went wrong';
  toast(message);
}

A Bonus Lie That Lives in Your Config

const items: Item[] = [];
const first = items[0];
first.name; // typed as Item, crashes at runtime

Array index access is typed as Item, not Item | undefined, because the compiler cannot know the length. One line in tsconfig.json fixes it:

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true
  }
}

This flag is not part of strict, so most projects never turn it on. It adds a few extra checks, and every one of them is a real case where the array could have been empty.

The Rule

A cast is a promise you make to the compiler that it cannot verify. Data from outside your program needs a runtime check, not a type assertion.

An easy audit: search your project for as and for !. and !;. For each hit, ask what happens when the assumption is false. Casts on your own literals are usually fine. Casts on network responses, environment variables, search results and caught errors are where the bugs live.

I keep these checks in the shared lib/ folder of the TypeScript-first templates on pixelanas.com, so a missing environment variable or a changed API shape fails loudly on the first request instead of silently in production.

Get the templates: https://pixelanas.gumroad.com

How many as casts does your project have, and how many of them are on data you do not control? Drop your count in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Fix: useSearchParams() Should Be Wrapped in a Suspense Boundary (and Why It Only Breaks at Build)

Anas Sheikh — Sat, 17 Oct 2026 09:54:51 +0000

You add a small search box to your navbar. It reads the query string, so you reach for useSearchParams(). Everything works in next dev. You push, the deploy fails, and the build log says:

useSearchParams() should be wrapped in a suspense boundary at page "/about".
Read more: https://nextjs.org/docs/messages/missing-suspense-with-csr-bailout

Notice the page name. You did not touch /about. That detail is the whole story.

The Code That Triggers It

// components/SearchBox.tsx
'use client';

import { useSearchParams } from 'next/navigation';

export function SearchBox() {
  const searchParams = useSearchParams();
  const query = searchParams.get('q') ?? '';

  return <input defaultValue={query} placeholder="Search..." />;
}

// app/layout.tsx
import { SearchBox } from '@/components/SearchBox';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <nav>
          <SearchBox />
        </nav>
        {children}
      </body>
    </html>
  );
}

Nothing here looks wrong, and next dev agrees with you.

Why Only the Build Complains

At build time, Next.js tries to pre-render every page that does not obviously need request data into static HTML. That is the fast path, and it is the default.

But a static page is built once, before any visitor exists, so it has no query string. useSearchParams() needs one. Next.js handles this by bailing out of static rendering for that part of the tree: the component is skipped on the server and rendered in the browser instead.

The catch is how far the bail-out spreads. Without a Suspense boundary around the component, the nearest boundary is the page itself, which would turn the whole page into client-side rendering and quietly throw away the static HTML you were about to ship. Instead of letting that happen silently, the build fails and asks you to say where the boundary should be.

Dev mode renders every page on demand, so it never has to make that decision, which is why the error only shows up when you build.

Why It Hits Every Page at Once

I put the component in layout.tsx on purpose. A shared layout wraps every page, so one unguarded useSearchParams() in a navbar breaks the build for /, /about, /pricing and every other static route at the same time.

That is also why the error names a page you never edited. The problem lives in a shared component.

Fix 1: Wrap the Component in Suspense

// app/layout.tsx
import { Suspense } from 'react';
import { SearchBox } from '@/components/SearchBox';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <nav>
          <Suspense fallback={<input disabled placeholder="Search..." />}>
            <SearchBox />
          </Suspense>
        </nav>
        {children}
      </body>
    </html>
  );
}

Now only the search box is rendered in the browser. Everything else stays static HTML. The fallback is what visitors see until the client takes over, so make it the same size as the real component to avoid the layout jumping when it swaps in.

This is the fix to reach for first. It keeps your pages static and limits the client-side part to the one component that needs it.

Fix 2: Read the Params on the Server and Pass Them Down

If the value is only needed on one page, skip the hook entirely. Pages receive searchParams as a prop:

// app/search/page.tsx
export default async function SearchPage({
  searchParams,
}: {
  searchParams: Promise<{ q?: string }>;
}) {
  const { q } = await searchParams;
  return <SearchResults query={q ?? ''} />;
}

In Next.js 15, searchParams is a Promise, so it has to be awaited. Reading it marks that page as dynamic, so it renders per request instead of at build time. For a real search results page that is exactly what you want.

Fix 3: Force the Route to Be Dynamic

export const dynamic = 'force-dynamic';

This also makes the error disappear, but it does so by giving up static rendering for the route. Use it when the page genuinely depends on the request, not as a way to silence the build. On a marketing page it trades speed for nothing.

Which Fix When

Situation	Fix
Small interactive component reads the URL (navbar search, filters, tabs)	Suspense around that component
An entire page depends on the query string	Read `searchParams` in the page
The page really is per-request	`force-dynamic`

A Detail Worth Knowing About the Fallback

Whatever sits inside the Suspense boundary is client-rendered, so it will not be in the initial HTML. For a search input that does not matter. For content you want indexed, keep it outside the boundary. A fallback that does not match the final size also adds layout shift, which counts against your Core Web Vitals. I cover what those metrics measure in this plain-language guide.

The Rule

A client component that reads request-time data needs a Suspense boundary, so Next.js knows how much of the page to make dynamic. Put the boundary as close to the component as you can, and the rest of the page stays static.

I wrap every URL-driven component this way across my Next.js templates, so the production build never depends on where a navbar or filter bar ends up in the layout.

Get the templates: https://pixelanas.gumroad.com

Search your project for useSearchParams and check that every use sits inside a Suspense boundary, especially anything imported by layout.tsx. If you have hit a different build-only error, drop it in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Your Server Action Error Messages Vanish in Production, and Throwing Is the Wrong Tool

Anas Sheikh — Fri, 16 Oct 2026 11:34:46 +0000

Here is a bug report you will eventually get: "The signup form told me what was wrong on your machine, but on the live site it just says something went wrong."

Nothing is broken. Next.js is doing this on purpose. But the code that triggers it looks completely normal, and it is in a lot of Server Actions tutorials, including a version in my own earlier post on replacing API routes.

The Code That Works Locally

// actions/signup.ts
'use server';

export async function signup(formData: FormData) {
  const email = formData.get('email') as string;

  const existing = await User.findOne({ email });
  if (existing) {
    throw new Error('That email is already registered');
  }

  await User.create({ email });
}

// components/SignupForm.tsx
'use client';

export function SignupForm() {
  const [error, setError] = useState('');

  async function handleSubmit(formData: FormData) {
    try {
      await signup(formData);
    } catch (e) {
      setError((e as Error).message);
    }
  }

  return (
    <form action={handleSubmit}>
      <input name="email" type="email" />
      <button type="submit">Sign up</button>
      {error && <p>{error}</p>}
    </form>
  );
}

In development, a duplicate email shows "That email is already registered". After next build and next start, or on Vercel, the same submission shows a generic message about an error occurring on the server, with a short digest string instead of your text.

Why Next.js Hides It

An error thrown on the server can carry anything: a database connection string inside a driver message, a file path, a query, a stack trace. If Next.js forwarded every thrown message to the browser, a single unexpected failure could leak internal details to anyone watching the network tab.

So in production builds, Next.js replaces the message of a thrown error with a generic one and attaches a digest, a short hash you can search for in your server logs. In development it shows you the real message because you are the only one looking.

That is the correct default. The mistake is using throw for something that is not an unexpected failure.

Two Kinds of Errors, Two Different Tools

Expected errors are things that will happen during normal use: a duplicate email, a wrong password, a failed validation, a card that was declined. The user should see a specific message and fix it.

Unexpected errors are things that should not happen: the database is down, a bug, a null that should not be null. The user should see a safe generic message and you should see the details in your logs.

throw is the right tool for the second kind. It is the wrong tool for the first, because the framework treats every thrown error as potentially sensitive and strips it.

The Fix: Return Expected Errors as Data

// actions/signup.ts
'use server';

import { z } from 'zod';

const SignupSchema = z.object({
  email: z.string().email('Enter a valid email'),
});

export type SignupState = {
  success: boolean;
  message?: string;
  fieldErrors?: Record<string, string[]>;
};

export async function signup(
  prevState: SignupState | null,
  formData: FormData
): Promise<SignupState> {
  const parsed = SignupSchema.safeParse({
    email: formData.get('email'),
  });

  if (!parsed.success) {
    return {
      success: false,
      fieldErrors: parsed.error.flatten().fieldErrors,
    };
  }

  const existing = await User.findOne({ email: parsed.data.email });
  if (existing) {
    return { success: false, message: 'That email is already registered' };
  }

  await User.create({ email: parsed.data.email });
  return { success: true, message: 'Account created' };
}

// components/SignupForm.tsx
'use client';

import { useActionState } from 'react';
import { signup } from '@/actions/signup';

export function SignupForm() {
  const [state, action, isPending] = useActionState(signup, null);

  return (
    <form action={action}>
      <input name="email" type="email" />
      {state?.fieldErrors?.email && <p>{state.fieldErrors.email[0]}</p>}
      <button type="submit" disabled={isPending}>
        {isPending ? 'Creating account...' : 'Sign up'}
      </button>
      {state?.message && <p>{state.message}</p>}
    </form>
  );
}

A returned value is just data. Next.js does not treat it as sensitive, so the exact same message reaches the user in development and in production. You also get useActionState handling pending state and the previous result for free, with no try/catch in the component.

Keep `throw` for the Real Failures

export async function signup(prevState, formData) {
  // ...expected errors returned as data above...

  try {
    await User.create({ email: parsed.data.email });
  } catch (error) {
    console.error('signup failed', error); // full details stay in your logs
    throw error; // user gets the safe generic message
  }

  return { success: true, message: 'Account created' };
}

When this throws in production, the user sees the generic message and an error boundary can take over. You search your logs for the digest and find the real error. Nothing sensitive reaches the browser.

Why This Survives Testing

Every manual test happens in next dev, where thrown messages are shown in full. The code looks perfect right up until the first production build, which is usually when real users start signing up.

The Rule

Return expected errors as data, throw only for unexpected failures. If a message is meant for the user to read, it should travel as a returned value. If it is meant for you to debug, it should go to your logs and surface to the user as something generic.

I use this return-a-state pattern in the forms and dashboard actions across my Next.js templates, so validation messages behave identically in development and on the live site.

Get the templates: https://pixelanas.gumroad.com

Search your own codebase for throw new Error inside files marked 'use server'. For each one, ask whether a user is supposed to read that message. If yes, it is probably already invisible in production. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Every Next.js Server Action Is a Public Endpoint, and Your bind(null, id) Is Not Protected

Anas Sheikh — Thu, 15 Oct 2026 12:09:29 +0000

There is a belief that quietly causes real vulnerabilities in Next.js apps: "Server Actions are internal, so the ID I pass into them is safe."

It is not. A Server Action is an HTTP endpoint with a generated URL, and anyone with a browser's network tab can call it with whatever arguments they want.

The Code That Looks Safe

// components/PostCard.tsx
import { deletePost } from '@/actions/posts';

export function PostCard({ post }: { post: Post }) {
  return (
    <form action={deletePost.bind(null, post.id)}>
      <button type="submit">Delete</button>
    </form>
  );
}

// actions/posts.ts
'use server';

export async function deletePost(id: string) {
  await connectDB();
  await Post.findByIdAndDelete(id);
  revalidatePath('/dashboard/posts');
}

This is the exact pattern most Server Actions tutorials teach, including a version of it in my own earlier post on replacing API routes. It works. The delete button deletes the post. It is also an insecure direct object reference, usually shortened to IDOR.

What an Attacker Actually Sees

When you bind an argument like post.id, Next.js serializes it into the form submission. Open the network tab, click Delete once on your own post, and you can see the request: an action identifier plus the bound ID.

Now replay that request with a different ID.

POST /dashboard/posts
Next-Action: 7f3c...a91
Body: ["64f1a2b3c4d5e6f7a8b9c0d1"]

If deletePost never checks who is calling it, that request deletes whichever post matches the ID, whether it belongs to the caller or to a completely different user. MongoDB ObjectIds are not secret. They are partly time-based and show up in URLs, API responses, and shared links, so assuming they are unguessable is a second mistake stacked on the first.

Why This Gets Missed

Three things hide this bug.

The UI only ever shows your own records. Every manual test uses a logged-in user clicking Delete on their own post. The code path works, so nothing fails.

The authentication check can pass while authorization is missing. Many Server Actions do check that someone is logged in. Being logged in is not the same as owning the record. Authentication asks "who are you." Authorization asks "is this yours."

Binding feels like closure, not input. deletePost.bind(null, post.id) reads like the ID is captured server-side. It is not. It is serialized to the client and comes back as a normal argument.

The Fix: Check Ownership Inside the Action

// actions/posts.ts
'use server';

export async function deletePost(id: string) {
  const session = await getServerSession();
  if (!session?.userId) {
    throw new Error('Unauthorized');
  }

  await connectDB();

  // The ownership check lives in the query itself
  const result = await Post.findOneAndDelete({
    _id: id,
    authorId: session.userId,
  });

  if (!result) {
    throw new Error('Not found');
  }

  revalidatePath('/dashboard/posts');
}

The important line is authorId: session.userId inside the query filter. The record is only found, and therefore only deleted, if it belongs to the person making the request. There is no separate "fetch then compare" step that someone can later forget or reorder.

Returning "Not found" for both a missing record and someone else's record is deliberate. It stops an attacker from learning which IDs exist.

Validate the Shape of the Argument Too

Arguments are also untrusted in format, not only in ownership. An ID that is not a valid ObjectId can throw confusing errors or, depending on your query, behave unexpectedly.

import { z } from 'zod';

const IdSchema = z.string().regex(/^[a-f\d]{24}$/i);

export async function deletePost(rawId: string) {
  const id = IdSchema.parse(rawId);
  // ...
}

The Rule

Treat every Server Action like a public API route: authenticate the caller, authorize the specific record, and validate the arguments. The fact that it is a function call in your component tree changes how it feels to write, not how it behaves on the network.

A quick audit works well: search your codebase for every file with 'use server' and look at each exported function. For each one, ask where it checks that the current user is allowed to touch the specific record it received.

I build this ownership-in-the-query pattern into the dashboard code across my Next.js templates, because it is easy to get right at the start and painful to retrofit across dozens of actions later.

Get the templates: https://pixelanas.gumroad.com

Go open one of your own delete or update actions right now and check whether the query filters by the current user. If it does not, you have found your first one. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Why Your Tailwind Classes Work in Development and Silently Vanish in Production

Anas Sheikh — Wed, 14 Oct 2026 07:53:56 +0000

Almost every Tailwind developer hits this exact bug once, usually right after a deploy, and the confusing part is that nothing about it looks wrong in the code, nothing throws an error, and it worked completely fine five minutes earlier on the same machine.

The Code That Looks Completely Reasonable

function StatusBadge({ status }: { status: 'success' | 'warning' | 'error' }) {
  const color = status === 'success' ? 'green' : status === 'warning' ? 'yellow' : 'red';

  return (
    <span className={`bg-${color}-100 text-${color}-800 px-2 py-1 rounded`}>
      {status}
    </span>
  );
}

In development, this renders exactly as expected, colored badges for each status, built dynamically from a single reusable component instead of three separate hardcoded ones. Then you deploy, and every badge renders as a plain, unstyled span. No color, no padding in some setups, nothing, depending on exactly what else got purged alongside it.

Why This Happens: Tailwind Doesn't Actually Execute Your Code

Tailwind doesn't run your JavaScript to figure out which classes you're using. It scans your source files as plain text, looking for strings that match known utility class patterns, and only generates CSS for the classes it actually finds written out, literally, somewhere in that scanned text.

className={`bg-${color}-100 text-${color}-800`}

Tailwind's scanner sees the literal text bg-${color}-100, not bg-green-100, bg-yellow-100, or bg-red-100. Template literal interpolation happens at runtime, in the browser or on your server, long after Tailwind's build step has already finished scanning your source files and generating the final CSS. Since none of the three actual color classes your component needs ever appears as literal, complete text anywhere in your codebase, Tailwind never generates CSS for any of them, and the class names that do get applied to the DOM at runtime simply don't exist in your stylesheet at all.

Why This Specifically Survives Local Development

This is the part that makes the bug genuinely sneaky rather than just a misunderstanding: in development mode, especially with certain dev server configurations or cached builds from before the dynamic class was introduced, you can sometimes see the correct styling anyway, either because an earlier full build still has the class generated from some other literal usage elsewhere in the project, or because of how some dev tooling handles incremental rebuilds. The failure shows up specifically in a clean production build, which scans and purges from scratch, with nothing left over from earlier development sessions to accidentally mask the problem.

The Fix: Always Write Complete Class Names, Literally

function StatusBadge({ status }: { status: 'success' | 'warning' | 'error' }) {
  const styles = {
    success: 'bg-green-100 text-green-800',
    warning: 'bg-yellow-100 text-yellow-800',
    error: 'bg-red-100 text-red-800',
  };

  return (
    <span className={`${styles[status]} px-2 py-1 rounded`}>
      {status}
    </span>
  );
}

Every complete, literal class name Tailwind needs now appears as actual text somewhere in the source file, bg-green-100, bg-yellow-100, bg-red-100, text-green-800, and so on, even though the specific one that gets applied is still chosen dynamically at runtime based on status. Tailwind's scanner finds all three as literal strings during the build, generates CSS for all three, and the correct one gets applied correctly regardless of which branch of the mapping object actually executes.

The Rule That Generalizes Beyond This One Example

Tailwind only generates CSS for class names that exist as complete, literal text somewhere in your scanned source files, string concatenation and template literal interpolation don't count, no matter how confident the resulting string looks at runtime. This applies to any dynamic styling pattern, not just color variants, conditionally built spacing classes, responsive variants built from a variable, state-based classes constructed from a prop, all of them need the complete literal class name written out somewhere Tailwind's scanner can see it, usually in a lookup object exactly like the one above, rather than assembled through string interpolation.

I keep every dynamic variant mapped out explicitly like this across the component libraries in my Next.js and Tailwind templates, specifically because this exact bug is so easy to reintroduce months later when someone, often future-you, refactors a component back toward the more compact-looking interpolated version without remembering why it was written the longer way.

Get the templates: https://pixelanas.gumroad.com

Go check your own codebase for className={...${variable}...} patterns building Tailwind classes dynamically. If you find one, do a clean production build and actually look at it, don't trust how it renders in dev. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Your Next.js Page Might Be Caching One User's Data and Serving It to Everyone Else

Anas Sheikh — Tue, 13 Oct 2026 09:45:53 +0000

This is the kind of bug that goes from "works perfectly in every test" to "actively leaking one customer's data to another customer" without a single code change in between, purely because of how caching and personalization interact in a way that isn't obvious from reading the component code.

The Setup

// app/dashboard/page.tsx
export default async function DashboardPage() {
  const session = await getServerSession();
  const user = await User.findById(session.userId);

  return (
    <div>
      <h1>Welcome back, {user.name}</h1>
      <p>Account balance: {user.balance}</p>
    </div>
  );
}

This looks obviously personalized, it reads the session, looks up the specific user, renders their specific data. There's nothing here that looks like it needs special caching considerations. That assumption is exactly where this goes wrong.

Why Next.js Can Get This Wrong

Next.js's App Router tries to statically render as much as possible by default, for good performance reasons. A page gets treated as static (cacheable, shared across all visitors) unless something in it signals that it needs to be dynamic (rendered fresh per-request). Specific APIs, reading cookies(), headers(), or searchParams directly, are what tell Next.js a page actually depends on request-specific data and needs dynamic rendering.

The problem is that getServerSession() in the example above may, depending on exactly how it's implemented and which auth library version you're on, read the session cookie in a way that doesn't always propagate that dynamic signal up to the page itself, especially if the cookie read happens inside a library function several layers removed from the page component, rather than a direct cookies() call visible in the page's own code. When that signal doesn't propagate correctly, Next.js can determine the page is eligible for static optimization, render it once during the build or on first request, and then serve that exact same rendered HTML, including the first user's name and balance, to every subsequent visitor who hits that route, until the cache naturally expires or gets invalidated.

Why This Is Specifically Dangerous, Not Just Buggy

A caching bug that shows stale content is annoying. A caching bug that shows a different user's personal data is a real data exposure incident, and the specific danger here is that it doesn't look like a caching bug from the outside, it looks like the application is broken for that specific user, showing someone else's name and balance, which can easily get reported and triaged as "a display bug" rather than correctly identified as a serious caching and session isolation issue.

Why This Survives Normal Testing

Testing a dashboard page almost always means logging in as a specific test user and confirming their own correct data renders. That test passes regardless of whether the response got cached and shared or genuinely rendered fresh for that specific request, because from a single test account's perspective, the result looks identical either way. The bug only becomes visible with two separate user sessions hitting the same route in a way that reveals the cached response is actually shared, which isn't a scenario most manual or automated testing naturally covers.

The Fix: Force Dynamic Rendering Explicitly for Anything Personalized

Don't rely on an auth helper's internal implementation to correctly signal dynamic rendering. State it explicitly for any route serving per-user data:

// app/dashboard/page.tsx
export const dynamic = 'force-dynamic';

export default async function DashboardPage() {
  const session = await getServerSession();
  const user = await User.findById(session.userId);

  return (
    <div>
      <h1>Welcome back, {user.name}</h1>
      <p>Account balance: {user.balance}</p>
    </div>
  );
}

The export const dynamic = 'force-dynamic' line removes any ambiguity about whether the page qualifies for static optimization. It costs the performance benefit of static rendering for that specific route, which is the correct tradeoff for anything genuinely personalized, that cost is real but small compared to the alternative.

An equally valid alternative is calling cookies() or headers() directly inside the page itself, rather than only inside a wrapped auth helper function, since a direct call from the page component is what reliably signals dynamic rendering without depending on how a library internally implements its own session check.

import { cookies } from 'next/headers';

export default async function DashboardPage() {
  cookies(); // explicit, direct call signals dynamic rendering regardless of what getServerSession does internally
  const session = await getServerSession();
  // ...
}

The Rule

Any page serving per-user or per-request data needs to explicitly and verifiably opt out of static rendering, not just assume an auth library's internals do that correctly on its behalf. This matters more, not less, as auth libraries and caching layers evolve between versions, since a signal that correctly propagated in one version can silently stop doing so after an update you didn't closely audit.

I treat every authenticated dashboard route as explicitly force-dynamic by default in the Next.js dashboard templates I build, specifically because the cost of guessing wrong here is a real user data leak, not just a stale page.

Get the templates: https://pixelanas.gumroad.com

Go check your own authenticated pages for an explicit dynamic export or a direct cookies()/headers() call, rather than relying on an auth helper to signal it correctly on your behalf. If you're not sure, this is worth verifying with two separate logged-in sessions today, not assuming. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Your Mongoose pre('save') Hook Is Being Silently Skipped by Half Your Update Calls

Anas Sheikh — Mon, 12 Oct 2026 10:37:35 +0000

This is one of the more consequential Mongoose gotchas because of exactly what tends to live inside a pre('save') hook, password hashing, slug generation, validation logic, and exactly which methods silently bypass it without ever telling you.

The Setup

// models/User.ts
const userSchema = new Schema({
  email: String,
  password: String,
});

userSchema.pre('save', async function (next) {
  if (this.isModified('password')) {
    this.password = await bcrypt.hash(this.password, 12);
  }
  next();
});

export const User = model('User', userSchema);

Create a new user with User.create() or new User(data).save(), and this works exactly as intended. The password arrives hashed, every time, without the rest of your codebase needing to remember to call bcrypt.hash manually anywhere. It feels like a solved problem.

Where It Actually Breaks

// A password reset flow
export async function resetPassword(userId: string, newPassword: string) {
  await User.findByIdAndUpdate(userId, { password: newPassword });
}

This runs without error. It updates the user's password field in the database. It also never calls pre('save'), which means the password gets stored in plain text, directly in your database, with no error, no warning, and a function name, findByIdAndUpdate, that reads as a completely reasonable, idiomatic way to update a user record.

findByIdAndUpdate, findOneAndUpdate, updateOne, and updateMany all operate directly against MongoDB's update commands. They don't instantiate a full Mongoose document and call .save() on it internally, they issue an update operation straight to the database. Mongoose's document middleware, including pre('save'), only runs on document instances that actually go through .save(). These query-based update methods structurally never touch that code path at all.

Why This Specifically Gets Missed

Both approaches, .save() and findByIdAndUpdate, look like equally valid, equally idiomatic ways to update a Mongoose document, and most Mongoose tutorials use both interchangeably without flagging that they behave completely differently with respect to middleware. A codebase that uses .save() for creating users and findByIdAndUpdate for updating them, which is an extremely common and reasonable-looking pattern, ends up with password hashing that works perfectly at signup and silently doesn't exist at all for a password reset, profile update, or admin-initiated password change, unless someone happens to specifically test that exact path with a tool that shows raw database contents.

The Fix: Use Query Middleware, Not Just Document Middleware

Mongoose provides a separate middleware hook specifically for query-based update methods:

userSchema.pre('findOneAndUpdate', async function (next) {
  const update = this.getUpdate() as any;

  if (update.password) {
    update.password = await bcrypt.hash(update.password, 12);
  }

  next();
});

This specifically targets findOneAndUpdate and findByIdAndUpdate (which is implemented as a wrapper around findOneAndUpdate internally). updateOne and updateMany need their own separate middleware registration, since Mongoose treats each query method as its own distinct middleware hook rather than one unified "any kind of update" event:

userSchema.pre('updateOne', async function (next) {
  const update = this.getUpdate() as any;
  if (update.password) {
    update.password = await bcrypt.hash(update.password, 12);
  }
  next();
});

A More Defensive Alternative: Standardize on One Update Path

Registering middleware separately for every query method Mongoose offers is viable but easy to let drift out of sync as new update call sites get added later by someone who doesn't know this distinction exists. A more durable fix for anything genuinely sensitive, like password handling, is routing all updates through a single service function that always uses .save() internally, rather than letting findByIdAndUpdate calls for that model spread throughout the codebase:

// services/userService.ts
export async function updateUser(userId: string, data: Partial<UserInput>) {
  const user = await User.findById(userId);
  if (!user) throw new Error('User not found');

  Object.assign(user, data);
  await user.save(); // always goes through pre('save') middleware
  return user;
}

This trades a small amount of performance, an extra read before the write, for a guarantee that every update for this model goes through the exact same validation and transformation logic, with no separate middleware registration required for each query method and no risk of a future findByIdAndUpdate call quietly skipping it.

The Rule

Anything inside a pre('save') hook only runs for updates that go through .save(), never for findOneAndUpdate, findByIdAndUpdate, updateOne, or updateMany. For any logic where skipping it has real consequences, password hashing being the clearest example, either register the equivalent query middleware for every update method your codebase actually uses, or standardize on a single service function that always goes through .save().

I route every sensitive field update through a dedicated service layer exactly like this in the auth code behind my Next.js and MongoDB templates, specifically because this gap is easy to introduce the moment a second developer, or a future version of yourself, reaches for the more convenient-looking findByIdAndUpdate call.

Get the templates: https://pixelanas.gumroad.com

Go check your own password reset, profile update, and admin edit flows for a findByIdAndUpdate or updateOne call on a model with password hashing in pre('save'). If you find one, check what's actually sitting in that field in your database right now. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Your NextAuth callbackUrl Might Be an Open Redirect Waiting to Happen

Anas Sheikh — Sun, 11 Oct 2026 14:20:16 +0000

Redirecting a user back to the page they were trying to reach after they log in is good, expected UX. Nobody wants to log in and land back on the homepage when they were actually trying to read a specific article or check out a specific product. The common way this gets implemented is also a common way to accidentally build an open redirect vulnerability directly into your auth flow.

The Pattern That Looks Completely Reasonable

// app/login/page.tsx
export default function LoginPage({ searchParams }: { searchParams: { callbackUrl?: string } }) {
  return (
    <form action={async (formData: FormData) => {
      'use server';
      const result = await signIn('credentials', {
        email: formData.get('email'),
        password: formData.get('password'),
        redirect: false,
      });

      if (result?.ok) {
        redirect(searchParams.callbackUrl || '/dashboard');
      }
    }}>
      {/* form fields */}
    </form>
  );
}

This is a genuinely common pattern, a protected page redirects an unauthenticated visitor to /login?callbackUrl=/dashboard/reports, and after a successful login, the app sends them back to wherever that parameter points. It works correctly, and it feels like a small, harmless convenience feature, right up until someone realizes that callbackUrl value came straight from a query string the visitor controls entirely.

What an Attacker Actually Does With This

https://yourapp.com/login?callbackUrl=https://evi1-yourapp-login.com/phish

If your redirect logic trusts the callbackUrl value without validating that it actually points somewhere inside your own app, a victim who clicks a link like this, maybe from a phishing email that looks legitimate because the domain in the visible link is genuinely yourapp.com, logs in successfully on your real site, with their real credentials, and then gets silently redirected to an attacker-controlled page immediately afterward. That page can look like anything, a fake "session expired, please log in again" prompt designed to harvest the same credentials a second time, now with the victim's guard completely down because they just successfully authenticated on the real site seconds earlier.

This is specifically dangerous because every part of the actual login happened on your real, legitimate domain. Nothing about the login page itself looked suspicious, because it wasn't, the vulnerability is entirely in what happens after a genuine, successful login.

Why This Is Easy to Miss

Redirect-after-login code gets tested by developers clicking through their own app, which only ever produces callbackUrl values that point to real internal pages, because that's the only way anyone naturally encounters this flow during development. The idea of someone deliberately crafting a malicious external value for this parameter doesn't come up unless security testing specifically targets it, since from a pure functionality standpoint, the feature works perfectly for every normal case anyone would think to try.

The Fix: Validate the Redirect Target Is Actually Internal

// lib/safe-redirect.ts
export function getSafeRedirectUrl(callbackUrl: string | undefined, fallback = '/dashboard'): string {
  if (!callbackUrl) return fallback;

  // Reject anything that isn't a relative path starting with exactly one slash.
  // "//evil.com" and "https://evil.com" both get rejected here,
  // protocol-relative URLs are a classic bypass for a naive check.
  if (!callbackUrl.startsWith('/') || callbackUrl.startsWith('//')) {
    return fallback;
  }

  return callbackUrl;
}

if (result?.ok) {
  redirect(getSafeRedirectUrl(searchParams.callbackUrl));
}

The specific check for a leading // matters more than it looks like it should. A browser interprets //evil.com as a protocol-relative URL, meaning it resolves to https://evil.com using whatever protocol the current page is on, and a naive check that only verifies "does this start with a single slash" can be bypassed entirely by that exact pattern. Rejecting anything that doesn't match a genuine single-slash-prefixed relative path closes this specific gap.

If you're using NextAuth's built-in redirect callback, the same principle applies there directly, NextAuth exposes a redirect callback specifically so you can validate target URLs centrally:

// auth.ts
export const authOptions: NextAuthOptions = {
  callbacks: {
    async redirect({ url, baseUrl }) {
      // Only allow redirects to the same origin as the app itself
      if (url.startsWith(baseUrl)) return url;
      if (url.startsWith('/')) return `${baseUrl}${url}`;
      return baseUrl;
    },
  },
};

The Rule

Any redirect target sourced from user-controllable input, a query parameter, a form field, a referrer header, needs to be validated as pointing somewhere inside your own app before you redirect to it. "It's just a convenience redirect" is exactly the framing that makes this vulnerability easy to introduce without noticing, since the feature's happy path looks completely benign and only the deliberately crafted input reveals the gap.

I validate every redirect target this way in the auth flows across my Next.js dashboard templates, since login and post-auth redirects show up in basically every project and this is a genuinely easy detail to skip under normal development pressure. More on the broader auth patterns I build around at pixelanas.com.

Get the templates: https://pixelanas.gumroad.com

Go check your own login flow for a callbackUrl, returnTo, or next parameter that gets redirected to without validation. If you find one, try crafting a //evil.com style value against it. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Your Next.js Middleware Matcher Config Is Probably Skipping Routes You Think It Protects

Anas Sheikh — Sat, 10 Oct 2026 12:57:59 +0000

Middleware feels like the cleanest way to gate an entire section of a Next.js app behind auth, one file, one config, covering everything under a path. That confidence is exactly the problem, because the matcher config that's supposed to define "everything under this path" has a few specific gaps that don't show up until someone hits a nested route that quietly skipped the check entirely.

The Setup That Looks Complete

// middleware.ts
import { NextResponse } from 'next/server';
import { getToken } from 'next-auth/jwt';

export async function middleware(request: NextRequest) {
  const token = await getToken({ req: request });

  if (!token) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: '/dashboard/:path*',
};

This reads as "protect everything under /dashboard," and for the routes most people test during development, /dashboard, /dashboard/settings, /dashboard/analytics, it works exactly as expected. The gap shows up specifically with route groups and parallel/intercepting route conventions, which don't map onto the URL path the way the folder structure visually suggests they do.

Where It Actually Breaks

app/
├── (dashboard)/
│   ├── dashboard/
│   │   └── page.tsx          → /dashboard
│   └── settings/
│       └── page.tsx          → /settings  (NOT /dashboard/settings!)

Route groups, the parenthesized folders, don't appear in the URL at all. A page at app/(dashboard)/settings/page.tsx is served at /settings, not /dashboard/settings, even though it visually sits inside what looks like your dashboard's folder in the codebase. A matcher: '/dashboard/:path*' pattern never matches /settings, because as far as the URL is concerned, it was never under /dashboard to begin with.

This is exactly the kind of structural confusion that's easy to carry forward from a folder structure that leans on route groups for layout purposes, the same route groups I use throughout the Next.js templates on pixelanas.com, without re-checking that every protected page's actual URL still falls inside the matcher pattern protecting it, because the folder nesting and the URL nesting have quietly diverged.

A Second, Subtler Gap: Matcher Patterns and Encoded Characters

Next.js's own documentation for the matcher config notes that values must be literal strings or simple patterns, matcher patterns don't support arbitrary regex features, and certain edge cases around encoded path segments or unusual characters in dynamic segments can fail to match in ways that aren't obvious from reading the pattern itself. A route like /dashboard/reports/q1%2F2026 (an encoded slash inside a dynamic segment) can behave unpredictably against a pattern that looks like it should obviously cover it.

Why This Doesn't Get Caught

Testing auth-gated routes usually means manually clicking through the main pages of a protected section, the ones directly nested under the obvious path, and confirming the redirect works. Pages that technically live in the same conceptual section of your app but sit outside the matched URL pattern because of a route group, or a page that was added later and happens to resolve to a URL slightly outside what the matcher covers, simply never get manually tested against the auth gate, because nobody thinks to check a URL that doesn't look like it needs checking.

The Fix: Verify Matcher Coverage Against Actual Resolved URLs, Not Folder Structure

Don't trust the matcher pattern based on how your app/ folder looks. Check it against the actual resolved URL of every page you intend to protect:

export const config = {
  matcher: [
    '/dashboard/:path*',
    '/settings/:path*',       // explicitly added once the real URL was checked
    '/billing/:path*',
  ],
};

A more defensive pattern for anything genuinely sensitive is inverting the logic entirely, protect everything by default, and explicitly exclude the few public routes, rather than trying to enumerate every protected path and hoping the list stays complete as the app grows:

export const config = {
  matcher: [
    '/((?!login|signup|api/public|_next/static|_next/image|favicon.ico).*)',
  ],
};

This pattern protects everything except the explicitly named public routes, which means a newly added page under a route group, or anywhere else, is protected by default rather than silently falling outside coverage until someone notices.

The Rule

A middleware matcher pattern should be verified against the app's actual resolved URLs, not assumed from how the app/ folder is visually organized. Route groups, parallel routes, and intercepting route conventions all affect the URL in ways that don't match the folder nesting, which is exactly where a matcher pattern that looks complete quietly isn't.

Get the templates: https://pixelanas.gumroad.com

Go check your own middleware matcher against the real URLs of every page it's supposed to protect, not the folder structure. If any of them use route groups, this is worth double-checking today. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

You Changed a User's Role in the Database, But Their JWT Doesn't Know That Yet

Anas Sheikh — Fri, 09 Oct 2026 13:24:58 +0000

You find out a user's permissions need to change right now, maybe they're being demoted from admin, maybe their account access is being revoked entirely after an incident. You update the database. The change looks instant in your admin panel. Meanwhile, that user keeps acting with their old permissions for as long as their existing session token stays valid, sometimes for hours, sometimes for days, and nothing about your database update touched that.

Why This Happens: JWTs Don't Check Back In

A JWT-based session, the kind most Next.js apps use with something like NextAuth, is a self-contained token. Once it's issued, your server verifies it by checking its signature and expiration, not by looking anything up in your database. That's the entire point of a stateless token, it avoids a database round trip on every single request.

// middleware.ts
export async function middleware(request: NextRequest) {
  const token = await getToken({ req: request });

  // This only checks: is the signature valid, has it expired?
  // It does NOT check: does this role still match what's in the database right now?
  if (token?.role !== 'admin') {
    return NextResponse.redirect(new URL('/unauthorized', request.url));
  }

  return NextResponse.next();
}

The role embedded in that token was correct the moment it was issued. It is not re-verified against the database on every request, because doing so would defeat the entire performance benefit of using a stateless token in the first place. If you update the user's role in the database five minutes after their token was issued, the token itself still says the old role, and will keep saying that until it expires and they're forced to log in again.

Where This Actually Causes Real Problems

For a routine role change, like a title update that doesn't affect sensitive access, a short delay before it takes effect is a minor inconvenience, at worst, mildly confusing. For a security-sensitive revocation, suspending an account after detecting suspicious activity, revoking admin access after an employee departure, removing a compromised API key's associated session, that same delay is a real exposure window. The access you believed you'd just shut off is still fully functional from the attacker's or departed employee's side, for however long their existing token remains valid.

Why This Is Easy to Miss Building the App

Session and role logic almost always gets tested by logging in fresh after making a change, which issues a brand new token with the updated role baked in, making the fix look like it worked perfectly. The actual bug only shows up for a user who's already logged in with an existing token at the moment the change happens, a scenario that's genuinely easy to never think to test, since it requires two separate sessions and specific timing to notice.

The Fix: Force Re-Verification for Anything Sensitive

The cleanest general fix is shortening token lifetime for sensitive roles and pairing it with refresh logic that re-checks the database:

// auth.ts (NextAuth config)
export const authOptions: NextAuthOptions = {
  session: {
    strategy: 'jwt',
    maxAge: 15 * 60, // 15 minutes instead of days, forces more frequent re-issuance
  },
  callbacks: {
    async jwt({ token, user, trigger }) {
      if (trigger === 'update' || !token.lastChecked || Date.now() - (token.lastChecked as number) > 60_000) {
        // Re-fetch the current role from the database periodically,
        // not just at initial login
        const dbUser = await User.findById(token.sub).select('role status');
        if (!dbUser || dbUser.status === 'suspended') {
          return { ...token, role: null, revoked: true };
        }
        token.role = dbUser.role;
        token.lastChecked = Date.now();
      }
      return token;
    },
  },
};

For genuinely urgent revocations, like an active security incident, token expiration alone isn't fast enough, and this is where some form of server-side revocation check becomes necessary, a denylist of revoked token IDs checked against a fast store like Redis, even if you're otherwise fully stateless everywhere else. It adds back a small lookup cost, but only for the specific case where "wait until the token expires naturally" genuinely isn't an acceptable answer.

// A minimal revocation check added to middleware
const isRevoked = await redis.sismember('revoked_sessions', token.jti);
if (isRevoked) {
  return NextResponse.redirect(new URL('/login', request.url));
}

The Rule

A JWT's claims are a snapshot from the moment it was issued, not a live view of your database. Any role or permission check based purely on token contents can be stale for as long as that token remains valid. For routine data, that staleness is usually an acceptable tradeoff for performance. For anything where immediate revocation actually matters, you need either short-lived tokens with periodic re-verification, or an explicit revocation check, because the token itself has no way of knowing anything changed.

I treat this distinction explicitly in the auth setup behind my Next.js dashboard templates, where role-based access control needs to actually mean something the moment it changes, not sometime later.

Get the templates: https://pixelanas.gumroad.com

Check your own app, specifically how fast a role change or account suspension actually takes effect for a user with an existing session. If the honest answer is "whenever their token expires," that's worth deciding on purpose rather than by default. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

DEV Community: Anas Sheikh

Your Next.js Dates Are Wrong for Half Your Users (and the Hydration Warning Is Only the Start)

The Code That Looks Fine

Why It Breaks

Why It Is Hard to Catch

The Fix That Is Tempting, and Wrong

Fix 1: Make the Output the Same on Both Sides

Fix 2: Show the Local Time After the Page Loads

Fix 3: Store and Send Dates as ISO Strings

Which One When

The Rule

forEach Doesn't Wait for Your await: The Bug That Makes APIs Reply Before the Work Is Done

The Code That Looks Fine

Why It Returns Early

Why It Is Hard to Catch

Fix 1: Need It Sequential? Use for...of

Fix 2: Need It Fast? Promise.all With map

Fix 3: Some Failures Are Acceptable? Use allSettled

Fix 4: Thousands of Items? Limit the Concurrency

Same Trap in filter, some, every and reduce

The Rule

Your TypeScript Is Lying to You, and These 5 Places Hide Real Bugs

1. Casting an API Response

2. The Non-Null Assertion on Environment Variables

3. The Non-Null Assertion on find()

4. Casting Object.keys

5. Casting the Caught Error

A Bonus Lie That Lives in Your Config

The Rule

Fix: useSearchParams() Should Be Wrapped in a Suspense Boundary (and Why It Only Breaks at Build)

The Code That Triggers It

Why Only the Build Complains

Why It Hits Every Page at Once

Fix 1: Wrap the Component in Suspense

Fix 2: Read the Params on the Server and Pass Them Down

Fix 3: Force the Route to Be Dynamic

Which Fix When

A Detail Worth Knowing About the Fallback

The Rule

Your Server Action Error Messages Vanish in Production, and Throwing Is the Wrong Tool

The Code That Works Locally

Why Next.js Hides It

Two Kinds of Errors, Two Different Tools

The Fix: Return Expected Errors as Data

Keep throw for the Real Failures

Why This Survives Testing

The Rule

Every Next.js Server Action Is a Public Endpoint, and Your bind(null, id) Is Not Protected

The Code That Looks Safe

What an Attacker Actually Sees

Why This Gets Missed

The Fix: Check Ownership Inside the Action

Validate the Shape of the Argument Too

The Rule

Why Your Tailwind Classes Work in Development and Silently Vanish in Production

The Code That Looks Completely Reasonable

Why This Happens: Tailwind Doesn't Actually Execute Your Code

Why This Specifically Survives Local Development

The Fix: Always Write Complete Class Names, Literally

The Rule That Generalizes Beyond This One Example

Your Next.js Page Might Be Caching One User's Data and Serving It to Everyone Else

The Setup

Why Next.js Can Get This Wrong

Why This Is Specifically Dangerous, Not Just Buggy

Why This Survives Normal Testing

The Fix: Force Dynamic Rendering Explicitly for Anything Personalized

The Rule

Your Mongoose pre('save') Hook Is Being Silently Skipped by Half Your Update Calls

The Setup

Where It Actually Breaks

Why This Specifically Gets Missed

The Fix: Use Query Middleware, Not Just Document Middleware

A More Defensive Alternative: Standardize on One Update Path

The Rule

Your NextAuth callbackUrl Might Be an Open Redirect Waiting to Happen

The Pattern That Looks Completely Reasonable

What an Attacker Actually Does With This

Why This Is Easy to Miss

The Fix: Validate the Redirect Target Is Actually Internal

The Rule

3. The Non-Null Assertion on `find()`

Keep `throw` for the Real Failures