DEV Community: Anas Sheikh

That .lean() Query Optimization Might Be Leaking Password Hashes in Your API Response

Anas Sheikh — Wed, 09 Sep 2026 08:20:08 +0000

I've recommended .lean() in earlier posts, it's genuinely the right call for read-heavy queries, faster, lighter, no Mongoose document overhead. There's a real gap it opens up that's worth calling out specifically, because it silently undoes a common, otherwise-good security pattern, and the failure is invisible unless you specifically go check the actual API response.

The Setup That Looks Like a Solid Security Pattern

// models/User.ts
const UserSchema = new Schema({
  name: String,
  email: String,
  password: { type: String, select: false }, // excluded from queries by default
}, {
  toJSON: {
    transform: (doc, ret) => {
      delete ret.password; // extra safety net, strips it even if somehow selected
      delete ret.__v;
      return ret;
    },
  },
});

This is a reasonable, defense-in-depth setup, select: false keeps the password out of normal queries by default, and the toJSON transform is a second safety net stripping it from anything that does get serialized, in case it was ever explicitly selected somewhere. Two layers, looks solid.

Where This Quietly Breaks

// app/api/users/route.ts
export async function GET() {
  const users = await User.find().select('+password').lean();
  // some legitimate internal reason to select password here, comparing hashes, an admin tool, etc.
  return Response.json({ users });
}

.lean() returns plain JavaScript objects, not real Mongoose documents. That toJSON transform you configured on the schema is a method that exists on Mongoose document instances specifically, it never runs on a plain object. Response.json({ users }) calls JSON.stringify under the hood, which on a lean plain object just serializes every property directly, no transform, no stripping, nothing. If password was selected anywhere in that query chain, it goes straight into the API response, completely bypassing the safety net you specifically built to prevent exactly that.

Why This Is Genuinely Easy to Introduce

The select('+password') and .lean() combination often gets added at different times, for different reasons, by different people, or by the same developer months apart with the original toJSON safety net long forgotten. Someone adds .lean() to a query for a legitimate performance reason, weeks or months after the select('+password') was added for some specific internal need, comparing a password during a migration script, an admin debugging tool, and neither change alone looks dangerous in isolation. The combination is what's dangerous, and nothing about reviewing either change independently reveals that.

The Actual Fix: Never Rely on toJSON as Your Only Safety Net

The real lesson here isn't "don't use .lean()", it's genuinely great for performance and you should keep using it. The lesson is that toJSON transforms are not a reliable safety net for anything you might combine with .lean(), so the actual stripping needs to happen explicitly, regardless of whether the query happens to be lean or not.

// lib/serializers/user.ts
export function toSafeUser(user: any) {
  const { password, __v, ...safe } = user;
  return safe;
}

// app/api/users/route.ts
import { toSafeUser } from '@/lib/serializers/user';

export async function GET() {
  const users = await User.find().lean(); // no need to select password here at all
  return Response.json({ users: users.map(toSafeUser) });
}

An explicit serializer function works identically whether the input came from a lean query or a real document, since it's just plain object destructuring, not relying on a Mongoose-specific lifecycle hook that only fires under certain conditions.

The Broader Rule This Points To

Never assume a security-relevant transform tied to a document lifecycle method still applies once you've introduced .lean(), .toObject(), or any pattern that returns a plain object instead of a real document instance. toJSON, toObject transforms, and virtuals are all Mongoose document features, tied specifically to the document class, not properties of the raw data itself. The moment you're working with a plain object, none of that schema-level behavior comes along automatically, and any security assumption riding on it needs to be re-verified explicitly, not assumed to still hold.

Check Your Own API Routes

grep -rn "lean()" --include="*.ts" app/api/

For each match, check two things, does the underlying query ever select a genuinely sensitive field, and does the response actually get filtered explicitly, not just relying on a schema-level transform that a lean query never triggers. If a route selects a sensitive field for some legitimate internal reason and also calls .lean(), that combination is worth verifying directly against the actual JSON response, not just the code.

If you've got .lean() anywhere near a query that ever selects a genuinely sensitive field, go check the actual raw response, not just the code, this specific combination is exactly the kind of thing that looks completely fine on read-through and only reveals itself in the real serialized output. Drop what you find in the comments.

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

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

Your JWT-Based Auth Might Let a Stolen Token Outlive a Password Reset

Anas Sheikh — Tue, 08 Sep 2026 08:10:42 +0000

I've written before about JWT in an httpOnly cookie as a solid auth pattern, and I stand by it, it closes off the most common token-theft path through XSS. There's a real, separate limitation worth being honest about though, one that's easy to overlook specifically because the pattern otherwise feels so solid.

The Core Tradeoff of Stateless Auth

A JWT's whole appeal is that verifying it doesn't require a database lookup, you check the signature, confirm it hasn't expired, and trust the payload. This is fast and simple, and it's also the exact reason a JWT can't be individually revoked once issued. There's no database record being checked and deleted, there's just a cryptographic signature that remains valid until its built-in expiration time arrives, regardless of anything that happens to the account in the meantime.

What This Actually Means in Practice

// lib/auth.ts
export function signToken(payload: SessionPayload): string {
  return jwt.sign(payload, JWT_SECRET, { expiresIn: '7d' });
}

export function verifyToken(token: string): SessionPayload | null {
  try {
    return jwt.verify(token, JWT_SECRET) as SessionPayload;
    // If this succeeds, the token is treated as valid. Nothing here checks
    // whether the account's password changed, or whether this specific
    // token was ever explicitly revoked.
  } catch {
    return null;
  }
}

With a 7-day expiration, a token issued today remains fully valid for the next 7 days, even if the account owner changes their password tomorrow, even if an admin bans the account the day after, even if the user explicitly logs out from every device they can find. If that token was ever stolen, copied from an insecure connection, extracted through some other compromise, "changing your password" does nothing to invalidate it. The stolen copy is still a completely valid credential until its own expiration clock runs out, independent of anything the actual account owner does.

Why This Surprises People

Most developers' mental model of "logging out" or "changing your password" implicitly assumes it invalidates existing sessions, because that's genuinely how session-based auth, the older, database-backed pattern, actually works, deleting a session record makes every reference to that session immediately worthless. JWT-based auth doesn't automatically inherit that property, and the pattern's real strength, avoiding a database check on every single request, is precisely what removes the natural point where revocation would happen.

The Actual Fix: A Deliberate Revocation Layer on Top

You don't have to abandon JWTs to fix this, you need one explicit, lightweight database check for a specific category of security-critical events, not on every single request.

// models/User.ts
const UserSchema = new Schema({
  // ...
  passwordChangedAt: Date, // updated whenever a password change happens
  tokensRevokedAt: Date,   // updated on "log out everywhere" or an admin-forced ban
});

// lib/auth.ts
export async function getSession(): Promise<SessionPayload | null> {
  const token = /* read from cookie */;
  const decoded = verifyToken(token);
  if (!decoded) return null;

  // One targeted check, not a full session lookup on every request
  const user = await User.findById(decoded.userId).select('passwordChangedAt tokensRevokedAt');
  if (!user) return null;

  const tokenIssuedAt = decoded.iat * 1000; // JWT 'iat' claim, in seconds

  if (user.passwordChangedAt && tokenIssuedAt < user.passwordChangedAt.getTime()) {
    return null; // token was issued before the most recent password change, reject it
  }

  if (user.tokensRevokedAt && tokenIssuedAt < user.tokensRevokedAt.getTime()) {
    return null; // explicitly revoked, e.g. "log out everywhere" or an admin action
  }

  return decoded;
}

This does add a database read back into session verification, which is a real, deliberate tradeoff against the pure-stateless approach's speed advantage. It's a reasonable one for most applications, since the alternative is a genuinely unbounded window where a compromised token remains fully valid no matter what the actual account owner does in response.

A Simpler Partial Mitigation: Just Shorten the Expiration

If a full revocation check feels like more infrastructure than a given project needs, the single cheapest mitigation is simply reducing how long a token stays valid in the first place, paired with a refresh token pattern to avoid forcing frequent re-logins.

// A short-lived access token, refreshed frequently
export function signAccessToken(payload: SessionPayload): string {
  return jwt.sign(payload, JWT_SECRET, { expiresIn: '15m' });
}

// A longer-lived refresh token, itself revocable since it IS checked against the database
export function signRefreshToken(payload: SessionPayload): string {
  return jwt.sign(payload, REFRESH_SECRET, { expiresIn: '7d' });
}

This shrinks the exposure window for a stolen access token from potentially a full week down to 15 minutes, while the refresh token, which actually gets checked against the database on each use, provides the real revocation point. It's more moving parts than a single long-lived token, but it directly addresses the actual gap rather than just hoping a token never gets stolen in the first place.

The Honest Tradeoff Summary

Pure stateless JWT, long expiration: fastest, simplest, and genuinely has no way to revoke a specific compromised token before it naturally expires.

JWT with a targeted revocation check (passwordChangedAt, tokensRevokedAt): adds one lightweight database read per session check, closes the actual gap, reasonable default for most real applications.

Short-lived access token plus revocable refresh token: more infrastructure, smallest possible exposure window, the choice for anything genuinely security-sensitive.

None of these are universally "correct," they're a real tradeoff between simplicity and how much exposure window you're comfortable accepting if a token is ever actually stolen.

If your app is running long-lived JWTs with no revocation check at all, worth deciding deliberately whether that's an acceptable tradeoff for what you're building, rather than an assumption nobody ever actually examined. Drop your own approach in the comments, curious how people are actually handling this across real projects.

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

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

Comparing Secrets with === in Your Next.js API Might Be Vulnerable to a Timing Attack

Anas Sheikh — Mon, 07 Sep 2026 08:48:34 +0000

This is one of those vulnerabilities that sounds theoretical right up until you see it actually demonstrated, and then it's hard to un-see in every piece of code comparing a secret with a plain ===.

The Setup That Looks Completely Reasonable

// app/api/webhooks/custom/route.ts
export async function POST(request: Request) {
  const providedSecret = request.headers.get('x-webhook-secret');

  if (providedSecret !== process.env.WEBHOOK_SECRET) {
    return new Response('Unauthorized', { status: 401 });
  }

  // process the webhook
}

This is checking a shared secret in a header, a common pattern for a custom webhook you control both sides of, an internal API key check, a CRON_SECRET verification, anything comparing a client-supplied value against a known correct one. The logic reads correctly. It's also, technically, exploitable, though the practical difficulty of actually pulling it off varies a lot depending on context.

Why === Leaks Timing Information

JavaScript's string equality comparison, like most languages' default string comparison, checks characters left to right and returns false the instant it finds a mismatch, without checking the remaining characters at all. This means comparing "a1234" against a correct secret "z9999" takes a tiny bit less time than comparing "a1234" against a correct secret starting with "a" but differing later, since the second comparison gets one character further before exiting.

That timing difference is measured in microseconds, genuinely tiny, but measurable, repeatable, and statistically extractable given enough attempts. An attacker who can send many requests and precisely measure response time can, in principle, determine a secret one character at a time, trying each possible next character and observing which one takes microscopically longer to reject, since a correct prefix means the comparison ran slightly further before failing.

Why This Is Genuinely Harder to Exploit Than It Sounds, But Not Impossible

This isn't a trivially easy, five-minute attack in most real deployments. Network jitter, server load variance, and the sheer number of requests needed to extract a meaningful timing signal all make this a genuinely difficult attack to pull off reliably over the open internet, and it's a much bigger concern for something like an internal service on a low-latency, controlled network than for a public API with normal internet-level timing noise. That said, "harder to exploit" isn't "not exploitable," timing attacks against real systems have been demonstrated successfully in research and in the wild, and dismissing the entire vulnerability class as purely theoretical is exactly the assumption that makes it worth actually fixing rather than shrugging off.

The Actual Fix: Constant-Time Comparison

Node.js's built-in crypto module provides exactly the tool for this, timingSafeEqual, which compares two buffers in a way that always takes the same amount of time regardless of where or whether a mismatch occurs.

// lib/secureCompare.ts
import crypto from 'crypto';

export function secureCompare(a: string, b: string): boolean {
  const bufferA = Buffer.from(a);
  const bufferB = Buffer.from(b);

  // Buffers of different lengths would throw, so check length separately first,
  // this length check itself doesn't leak the actual secret's content
  if (bufferA.length !== bufferB.length) {
    return false;
  }

  return crypto.timingSafeEqual(bufferA, bufferB);
}

// app/api/webhooks/custom/route.ts
import { secureCompare } from '@/lib/secureCompare';

export async function POST(request: Request) {
  const providedSecret = request.headers.get('x-webhook-secret') ?? '';

  if (!secureCompare(providedSecret, process.env.WEBHOOK_SECRET as string)) {
    return new Response('Unauthorized', { status: 401 });
  }

  // process the webhook
}

timingSafeEqual always compares every byte, regardless of where a mismatch occurs, so the time taken no longer leaks any information about how much of the guess was actually correct.

Where This Applies in a Real Next.js Project

Anywhere a secret, token, or API key gets compared against a known correct value using plain equality. A custom webhook secret check, a CRON_SECRET header check, an internal API key validation, a manually-implemented session token comparison. It's worth noting Stripe's own SDK, stripe.webhooks.constructEvent, already handles this correctly internally, using proper signature verification rather than naive string comparison, so that specific, common case is already safe. The risk is specifically in custom comparisons you write yourself for secrets you control both sides of.

What This Doesn't Apply To

Comparing non-secret values, checking whether a status field equals "active", comparing a username for a lookup rather than an authentication decision, doesn't need constant-time comparison, since there's no secret whose value an attacker could meaningfully extract through timing. This matters specifically for genuine secrets and tokens, not general string equality throughout an app.

The Actual Checklist

Any custom secret or token comparison you write yourself should use crypto.timingSafeEqual, not ===.

Check the length first, separately, before calling timingSafeEqual, since it throws on mismatched buffer lengths rather than safely returning false, and a naive length check beforehand doesn't leak meaningful information the way comparing the actual secret content would.

Established libraries handling this internally, like Stripe's webhook verification, don't need this applied on top, check whether the library you're using already does it correctly before assuming you need to add your own layer.

If you have any custom secret comparison in your codebase using plain ===, worth checking today whether it's genuinely low-risk (an internal tool, unlikely target) or worth the small effort of switching to a constant-time comparison. Drop what you find in the comments.

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

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

Why Your MongoDB Check in Next.js Middleware Might Be Silently Failing

Anas Sheikh — Sun, 06 Sep 2026 08:44:33 +0000

I mentioned this briefly in an earlier post on middleware patterns, that direct database queries don't run reliably in middleware, and a few people asked what "not reliably" actually means in practice, since it sounds vague enough to ignore. It's worth a real, specific answer, because the actual failure mode here is genuinely easy to miss until it costs you something.

Why This Happens

Next.js middleware runs on the Edge Runtime by default, a deliberately restricted environment built for speed, running geographically close to the visitor rather than in one central server location. That speed comes from real constraints, the Edge Runtime doesn't support the full Node.js API surface, no fs module, limited or no support for certain networking and crypto APIs that Node.js provides natively.

Mongoose, and the underlying MongoDB Node.js driver it depends on, was built assuming a full Node.js environment. It uses APIs and networking behavior that the Edge Runtime doesn't fully support.

What This Actually Looks Like

// middleware.ts
import { connectDB } from '@/lib/db';
import User from '@/models/User';

export async function middleware(request: NextRequest) {
  await connectDB();
  const user = await User.findOne({ /* some lookup */ });
  // ...
}

Depending on your exact Next.js version, deployment platform, and what specifically the query does, this can fail in a few different ways, and none of them are a clean, obvious "Mongoose doesn't work here" error message. Sometimes it's a build-time error about an unsupported Node.js API being used. Sometimes it's a runtime error only surfacing in production, not locally. Sometimes, depending on caching and how the request happens to be handled, it appears to work in casual testing and then behaves inconsistently under real load or on a different deployment region. The inconsistency itself is what makes this dangerous, a bug that fails the same way every time is far easier to catch than one that only sometimes fails.

The Actual Fix: Opt Into the Node.js Runtime, or Move the Query Out

Next.js lets middleware explicitly opt into the full Node.js runtime instead of the Edge Runtime default, though this comes with real tradeoffs worth understanding, not just applying blindly.

// middleware.ts
export const config = {
  runtime: 'nodejs', // opts out of Edge Runtime, restores full Node.js API support
};

export async function middleware(request: NextRequest) {
  await connectDB();
  const user = await User.findOne({ /* ... */ });
  // ...
}

This genuinely fixes the compatibility problem, Mongoose now runs in an environment it actually supports. The tradeoff is losing the specific performance benefit the Edge Runtime provides, middleware no longer runs at the network edge closest to each visitor, it runs in a more traditional serverless environment, which can mean measurably slower middleware execution for a globally distributed audience.

The Better Fix, Usually: Don't Query the Database in Middleware at All

For the specific, extremely common case of an auth check, the better pattern avoids this tradeoff entirely by never needing a database query in middleware in the first place.

// middleware.ts (Edge Runtime, no database dependency at all)
import { verifyToken } from '@/lib/auth'; // verifies a signed JWT, no DB call needed

export function middleware(request: NextRequest) {
  const token = request.cookies.get('auth-token')?.value;
  const session = token ? verifyToken(token) : null;

  if (!session && request.nextUrl.pathname.startsWith('/dashboard')) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  return NextResponse.next();
}

A signed JWT can be verified using just its signature, a cryptographic check that doesn't require a database round trip at all, and that verification, done correctly, runs fine in the Edge Runtime. The actual database-backed check, confirming a user still exists, checking permissions that could have changed since the token was issued, belongs in the layout or page itself, which runs in the normal Node.js environment without any Edge Runtime restrictions.

// app/(dashboard)/layout.tsx (normal Node.js runtime, database queries fully supported)
export default async function DashboardLayout({ children }: { children: React.ReactNode }) {
  const session = await getSession(); // JWT already verified by middleware
  await connectDB();
  const user = await User.findById(session.userId); // safe here, full Node.js runtime
  // ...
}

This gets you the actual benefit middleware is good for, fast, edge-based routing decisions, without ever asking it to do something it was never built to support reliably.

The Actual Rule

Middleware should make routing decisions based on data it can access without a database, cookies, headers, a verified token's payload. Anything that genuinely needs a database lookup belongs in a layout, page, Server Action, or route handler, which all run in the full Node.js environment by default, not in middleware, which runs on the Edge Runtime unless explicitly configured otherwise, and even then, carries a real performance tradeoff for opting out.

Check Your Own Middleware

If your middleware.ts imports anything that eventually calls Mongoose, or any other database driver built for a full Node.js environment, that's worth checking today, especially if it's not throwing an obvious, consistent error, since the inconsistent version of this failure is the one that actually causes real production incidents nobody can easily reproduce.

If you've hit this, or something like it, in production, genuinely curious what the actual failure looked like on your end, a clean error, or something stranger and harder to pin down. Drop it in the comments.

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

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

A Wildcard in Your next.config Image remotePatterns Might Turn Your Site Into an SSRF Proxy

Anas Sheikh — Fri, 04 Sep 2026 10:18:07 +0000

next/image optimizing external images is genuinely convenient, resizing, format conversion, all handled automatically through Next.js's built-in image optimization endpoint. That endpoint fetches the remote image server-side before serving the optimized version to the browser, and that server-side fetch is exactly the mechanism that becomes a real problem if remotePatterns is configured too loosely.

The Configuration That Looks Convenient

// next.config.ts
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: '**', // "just let any https image load, easier than maintaining a list"
      },
    ],
  },
};

This shows up constantly, especially on projects where images come from a genuinely wide variety of sources, user-uploaded content pointing at various CDNs, a CMS that could reference images from anywhere. The wildcard hostname feels like a reasonable convenience, avoid maintaining an explicit allowlist, just accept any https image URL.

Why This Is Actually a Real Vulnerability

Next.js's image optimization endpoint, /_next/image, accepts a url parameter and fetches it server-side. With hostname: '**', that endpoint will fetch essentially any URL an attacker provides, as long as it's https. This turns your own server into a general-purpose URL-fetching proxy, controllable by anyone who can construct a request to that endpoint, which is a textbook Server-Side Request Forgery setup.

https://yoursite.com/_next/image?url=https://internal-admin-panel.yourcompany.com/&w=640&q=75

If your infrastructure has any internal services reachable from where your Next.js app runs, an internal admin panel, a cloud metadata endpoint, an internal API with no separate auth layer because it was assumed to only be reachable from inside your own network, a wildcard remotePatterns configuration means your own server will happily make that request on an attacker's behalf and, depending on exactly how the endpoint's response gets exposed, potentially leak some information about what came back.

The Specific, Well-Known Version of This: Cloud Metadata Endpoints

This is the classic SSRF target, and it's directly relevant here. Most cloud providers expose an internal metadata endpoint, http://169.254.169.254/, reachable only from within their own infrastructure, that can return real credentials or configuration data for the running instance. A wildcard image proxy is exactly the kind of mechanism that's been used in real-world SSRF attacks to reach exactly this endpoint from inside cloud environments, since the request originates from your own server, which does have network access to it, not from the attacker's machine, which doesn't.

The Fix: An Actual Allowlist, Not a Wildcard

// next.config.ts
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'res.cloudinary.com',
      },
      {
        protocol: 'https',
        hostname: 'yourbucket.s3.amazonaws.com',
      },
      {
        protocol: 'https',
        hostname: 'lh3.googleusercontent.com', // if accepting Google account avatars, for example
      },
    ],
  },
};

An explicit list of the actual, known image sources your app legitimately uses closes this off entirely. The image optimization endpoint will only fetch from hosts on this list, regardless of what URL parameter someone tries to pass in, which is the entire point, the server should only ever be willing to fetch from sources you've actually decided to trust, not from anywhere an attacker can construct a URL for.

What If You Genuinely Need Broad, User-Controlled Image Sources

For a case like user-generated content where images could legitimately come from many different, unpredictable domains, a wildcard isn't the only option, and it's worth resisting it even here. A more careful approach validates and stores the actual final image URL at upload time, ideally re-hosting the image on your own trusted storage rather than proxying an arbitrary external URL live on every request, which removes the SSRF surface entirely rather than trying to sanitize URLs on the fly, a genuinely hard problem to get completely right.

The Broader Rule

Any server-side mechanism that fetches a URL based on client-supplied input is a potential SSRF vector, and next/image's remotePatterns wildcard is a specific, easy-to-overlook instance of a much more general pattern. The same caution applies to any custom endpoint you build that fetches a URL, downloads a file, or proxies a request based on something a client sent, not just this one specific Next.js feature.

Check Your Own Config

grep -A 5 "remotePatterns" next.config.ts

If you see hostname: '**' or a similarly broad wildcard, and your app has any internal services or cloud infrastructure reachable from where it runs, this is worth tightening today, not eventually. Replace it with an explicit list of the actual domains your images genuinely come from.

If you're running a wildcard remotePatterns config right now, genuinely curious what led to it, deliberate convenience tradeoff, or just copied from a tutorial without thinking through what it actually opens up. Drop your situation in the comments.

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

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

Your useOptimistic UI Might Be Lying to Users When the Server Action Actually Fails

Anas Sheikh — Thu, 03 Sep 2026 07:02:27 +0000

useOptimistic is genuinely one of the nicer additions to React for making an app feel fast, updating the UI immediately while the real request happens in the background. It's also very easy to implement in a way that only handles the success path, leaving the UI confidently showing something that never actually happened once the request fails.

The Setup That Looks Complete

// components/TodoItem.tsx
'use client';
import { useOptimistic } from 'react';
import { toggleComplete } from '@/actions/todos';

export function TodoItem({ todo }: { todo: Todo }) {
  const [optimisticTodo, setOptimisticTodo] = useOptimistic(todo);

  async function handleToggle() {
    setOptimisticTodo({ ...todo, completed: !todo.completed });
    await toggleComplete(todo.id);
  }

  return (
    <div onClick={handleToggle}>
      <span className={optimisticTodo.completed ? 'line-through' : ''}>
        {optimisticTodo.title}
      </span>
    </div>
  );
}

This is close to the exact example from React's own docs, and it demonstrates the concept well. It also quietly assumes toggleComplete always succeeds, and doesn't do anything if it doesn't.

What Actually Happens When the Server Action Fails

useOptimistic's whole mechanism is that the optimistic value automatically reverts once the surrounding transition completes and the component re-renders with real data from the server. This part genuinely works as documented. The gap is what "real data from the server" actually means if toggleComplete threw an error, or returned a typed failure result, and nothing in this component ever surfaces that failure to the user.

If toggleComplete fails silently, network error, database error, an authorization check rejecting the change, the optimistic state briefly shows the toggled state, then reverts once the transition resolves, since the underlying todo prop never actually changed. From the user's perspective, they clicked a checkbox, watched it check, and then watched it silently un-check itself a moment later, with zero explanation of what happened or why. That's a genuinely confusing experience, and it's worse than not having optimistic UI at all, since it actively shows a false success before reverting rather than just taking a normal moment to update.

The Fix: Actually Handle the Failure Case

'use client';
import { useOptimistic, useState } from 'react';
import { toggleComplete } from '@/actions/todos';

export function TodoItem({ todo }: { todo: Todo }) {
  const [optimisticTodo, setOptimisticTodo] = useOptimistic(todo);
  const [error, setError] = useState<string | null>(null);

  async function handleToggle() {
    setError(null);
    setOptimisticTodo({ ...todo, completed: !todo.completed });

    const result = await toggleComplete(todo.id);

    if (!result.success) {
      setError('Could not update. Try again.');
      // optimisticTodo reverts automatically once this transition resolves,
      // since the real todo prop never actually changed
    }
  }

  return (
    <div>
      <div onClick={handleToggle}>
        <span className={optimisticTodo.completed ? 'line-through' : ''}>
          {optimisticTodo.title}
        </span>
      </div>
      {error && <p className="text-red-400 text-sm">{error}</p>}
    </div>
  );
}

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

export async function toggleComplete(id: string) {
  try {
    const todo = await Todo.findById(id);
    await Todo.findByIdAndUpdate(id, { completed: !todo.completed });
    revalidatePath('/todos');
    return { success: true };
  } catch (error) {
    return { success: false, message: 'Failed to update' };
  }
}

The optimistic revert still happens automatically, that part of useOptimistic was never broken. What's added is actually telling the user why it reverted, instead of leaving them to notice a checkbox silently un-checking itself and wonder if they imagined clicking it in the first place.

A Subtler Version of the Same Gap: Partial Failure in a List

// ❌ Doesn't distinguish which specific item's update actually failed
async function handleBulkComplete(ids: string[]) {
  ids.forEach((id) => setOptimisticTodos(prev => 
    prev.map(t => t.id === id ? { ...t, completed: true } : t)
  ));
  await Promise.all(ids.map(id => toggleComplete(id)));
  // if one of these failed, which one? the UI has no idea
}

When an optimistic update covers multiple items and only some of the underlying requests fail, Promise.all rejecting on the first failure, or resolving with a mix of success and failure results, needs to be handled per-item, not just as one collective success or failure. Otherwise a user bulk-completing five tasks might see all five check off, with no indication that one of them silently failed to actually save, until they refresh and find it unchecked again with zero explanation.

// ✅ Tracks and surfaces which specific items actually failed
async function handleBulkComplete(ids: string[]) {
  ids.forEach((id) => setOptimisticTodos(prev => 
    prev.map(t => t.id === id ? { ...t, completed: true } : t)
  ));

  const results = await Promise.allSettled(ids.map(id => toggleComplete(id)));
  const failedIds = ids.filter((id, i) => results[i].status === 'rejected');

  if (failedIds.length > 0) {
    setError(`${failedIds.length} item(s) failed to update`);
  }
}

The Actual Rule

Optimistic UI needs a real plan for the failure path, not just the happy path the demo shows. useOptimistic correctly reverts the visual state once real data doesn't match the optimistic guess, that mechanism works as intended. What it doesn't do automatically is explain to the user why something they just watched happen apparently didn't, and building that explanation in is the actual work optimistic UI adds on top of a normal loading state, not something that comes free with the hook itself.

If you've got useOptimistic in production, check what actually happens on a genuinely failed request, not just what the happy path demo shows. Kill your network connection mid-request and watch what the user actually sees. If it's a silent revert with no explanation, that's worth fixing. Drop what you find in the comments.

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

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

Using an Array Index as a React key Can Leak Form State Between Completely Different Items

Anas Sheikh — Wed, 02 Sep 2026 07:00:48 +0000

This is one of those React gotchas that's been written about for years and still shows up constantly in real code, specifically because it looks completely correct and works fine in the exact scenario most people test.

The Setup That Looks Fine

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

export function QueueList({ entries }: { entries: QueueEntry[] }) {
  return (
    <div>
      {entries.map((entry, index) => (
        <QueueRow key={index} entry={entry} />
      ))}
    </div>
  );
}

function QueueRow({ entry }: { entry: QueueEntry }) {
  const [isEditing, setIsEditing] = useState(false);
  const [note, setNote] = useState('');

  return (
    <div>
      {isEditing ? (
        <input value={note} onChange={(e) => setNote(e.target.value)} />
      ) : (
        <span>{entry.name}</span>
      )}
      <button onClick={() => setIsEditing(!isEditing)}>Edit</button>
    </div>
  );
}

key={index} compiles fine, renders fine, and works completely correctly for a list that never reorders or has items removed from the middle. It's also a ticking bug for the exact moment that stops being true, which, for a live queue, a to-do list, anything backed by real-time or user-driven changes, is basically guaranteed to happen eventually.

What Actually Breaks

Say a user clicks "Edit" on the third row in a five-person queue, typing a note into that row's input. Then, before they finish, the first person in the queue gets called and removed from the list. React re-renders with four entries instead of five, and here's the actual bug, React uses the key to decide whether a given DOM node and its associated state represent the same conceptual item across renders or a genuinely new one.

With key={index}, the item that used to be at index 3 (where the user was editing) is now a completely different person's data, since everyone shifted up by one position after the removal. But React sees key={2} existed before and key={2} exists now, same key, so as far as React's reconciliation is concerned, this is the same component instance, not a new one. The isEditing and note state that belonged to the original row stays attached to whatever now occupies that same index. The user's open text input, and whatever they'd started typing, is now sitting on a completely different person's row, potentially about to submit a note meant for someone else onto someone else's queue entry.

Why This Is So Easy to Miss in Testing

Most manual testing during development involves a list that doesn't change while you're interacting with it, you open an edit field, you look at it, maybe you close it, and move on. The bug specifically requires the list to reorder or shrink while some item has open local state, exactly the kind of timing-dependent interaction that's easy to never happen to trigger during normal development testing, and completely likely to happen in production the moment two things occur close together in real usage, someone editing a note right as a queue updates in real time, for instance.

The Fix: Key by Something Stable and Unique to the Item

export function QueueList({ entries }: { entries: QueueEntry[] }) {
  return (
    <div>
      {entries.map((entry) => (
        <QueueRow key={entry.id} entry={entry} /> {/* stable, unique, tied to the actual item */}
      ))}
    </div>
  );
}

Using the entry's actual database ID, something that stays attached to that specific piece of data regardless of its position in the array, means React correctly tracks each row as the same conceptual item across reorders and removals. If the person originally at index 3 moves to index 2 after someone ahead of them is removed, React now correctly recognizes it's the same person, keyed by entry.id, not a coincidentally-matching array position, and their open edit state, their typed note, moves correctly along with them instead of staying pinned to a now-different row.

Where This Specifically Bites Harder: AnimatePresence

This gets worse, not just wrong but visually confusing, combined with exit animations. If you're using AnimatePresence for a list, covered in an earlier post on animation patterns, keying by index actively breaks the exit animation's ability to correctly identify which item is actually leaving.

// ❌ AnimatePresence can't correctly animate the actual removed item
<AnimatePresence>
  {entries.map((entry, index) => (
    <motion.div key={index} exit={{ opacity: 0 }}>
      {entry.name}
    </motion.div>
  ))}
</AnimatePresence>

// ✅ Correctly animates the specific item that was actually removed
<AnimatePresence>
  {entries.map((entry) => (
    <motion.div key={entry.id} exit={{ opacity: 0 }}>
      {entry.name}
    </motion.div>
  ))}
</AnimatePresence>

With an index-based key, removing the first item doesn't register as "index 0 left," it registers as "every remaining item shifted to a new key," which can cause the exit animation to fire on the wrong visual element, or fail to trigger the intended fade-out on the item that was actually removed at all.

The Actual Rule

Any list where items can be reordered, filtered, or removed from anywhere other than strictly the end needs a key tied to the item's own stable identity, not its position. A database ID, a UUID, anything genuinely unique and attached to that specific piece of data works. Array index is only ever safe for a list that's guaranteed static, never reordered, never filtered, items only ever appended at the end and never removed, a genuinely narrow set of real-world cases.

Go check any list in your own codebase using key={index}, specifically ones with any local state inside each item, an expanded row, an open edit mode, a checked checkbox, and check whether that list can ever reorder or have items removed from the middle. If it can, this bug is very likely already there, whether or not anyone's noticed yet. Drop what you find in the comments.

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

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

Stop Using Array Index as a React Key. The Bug You Create Might Not Be Where You Think.

Anas Sheikh — Tue, 01 Sep 2026 17:08:26 +0000

Here's a React bug that's incredibly easy to write because the code looks completely reasonable.

You have a list:

{users.map((user, index) => (
  <UserCard
    key={index}
    user={user}
  />
))}

ESLint is happy.

React stops complaining about missing keys.

Your UI renders perfectly.

You ship it.

Then three weeks later someone adds sorting, filtering, deleting, drag-and-drop, or live updates.

Suddenly a checkbox belongs to the wrong user.

An input keeps someone else's value.

An animation happens on the wrong row.

A component's local state appears to randomly move around.

And you start debugging the database.

The database is fine.

React is doing exactly what you told it to do.

The problem is the key.

What React Actually Uses a Key For

A lot of developers think this:

key={user.id}

is basically an optimization hint.

It isn't.

Keys help React determine which item is which between renders.

Think about this list:

Alice
Bob
Charlie

with:

key={user.id}

React can identify:

Alice   → 101
Bob     → 102
Charlie → 103

Now imagine Alice is removed:

Bob
Charlie

React can understand:

101 disappeared
102 is still here
103 is still here

That's exactly what you want.

But now look at:

key={index}

Initially:

Alice   → 0
Bob     → 1
Charlie → 2

Remove Alice.

Your new list becomes:

Bob     → 0
Charlie → 1

From React's perspective, something very different happened.

The component that used to represent Alice now represents Bob.

The component that used to represent Bob now represents Charlie.

The identities shifted.

And that's where the weirdness starts.

The Classic Example: A Checkbox

Imagine:

function UserCard({ user }) {
  const [selected, setSelected] = useState(false);

  return (
    <div>
      <input
        type="checkbox"
        checked={selected}
        onChange={() => setSelected(!selected)}
      />

      {user.name}
    </div>
  );
}

Your list:

{users.map((user, index) => (
  <UserCard
    key={index}
    user={user}
  />
))}

The user checks:

☑ Alice
☐ Bob
☐ Charlie

Then Alice gets removed.

Your data is now:

Bob
Charlie

But React can reuse the existing component instances.

You might end up visually seeing:

☑ Bob
☐ Charlie

Bob never selected himself.

The component state simply followed the position instead of the user.

This is the kind of bug that makes developers say:

"I swear React is broken."

React isn't broken.

Your identity model is.

Why It Doesn't Happen Immediately

This is the important part.

If your list only ever grows:

Alice
Bob
Charlie
David

index keys may appear to work perfectly.

Nothing obviously breaks.

That's why this mistake survives code review.

The problem appears when the list changes in the middle.

For example:

remove
insert
sort
filter
reorder
drag-and-drop
pagination
live updates

The moment item positions change, index-based identity becomes unreliable.

Sorting Makes It Even More Obvious

Imagine:

1. Laptop
2. Keyboard
3. Mouse

Each row has:

const [expanded, setExpanded] = useState(false);

The user expands:

Laptop

Then they sort by price.

The new order becomes:

Mouse
Laptop
Keyboard

If you're using:

key={index}

React sees:

0 → something
1 → something
2 → something

The positions still exist.

But the actual items changed.

Now the expanded state can appear attached to the wrong product.

With:

key={product.id}

React knows:

Laptop is still Laptop.
It just moved.

That's the distinction.

The Fix Is Usually Ridiculously Simple

Instead of:

{products.map((product, index) => (
  <ProductCard
    key={index}
    product={product}
  />
))}

use:

{products.map((product) => (
  <ProductCard
    key={product.id}
    product={product}
  />
))}

Now the identity belongs to the data.

Not the position.

"But My Data Doesn't Have an ID"

This is where developers sometimes reach for:

key={Math.random()}

Please don't.

That's arguably worse.

Every render can generate a completely different key.

React may interpret your components as entirely new components.

That can cause:

unnecessary remounts
lost component state
broken animations
unnecessary DOM work
confusing lifecycle behavior

You want a key that's:

stable + unique among siblings

Good:

key={user.id}

Potentially good:

key={user.email}

if the email is guaranteed unique and stable.

Bad:

key={index}

for dynamic lists.

Very bad:

key={Math.random()}

What About `crypto.randomUUID()`?

You might think:

key={crypto.randomUUID()}

solves the problem.

It doesn't if you're generating it during rendering.

For example:

{items.map(item => (
  <Item
    key={crypto.randomUUID()}
    item={item}
  />
))}

You've created a new identity every time React renders.

That's not stable.

If you need IDs for newly created data, generate them when the item is created, store them with the item, and reuse them.

For example:

const newTodo = {
  id: crypto.randomUUID(),
  text: "Learn React",
};

Then:

<Todo
  key={todo.id}
  todo={todo}
/>

Now the identity survives re-renders.

There Is One Situation Where Index Keys Are Fine

This is where I don't want to turn this into:

"Never ever use index as a key."

That's too simplistic.

Index keys can be acceptable when the list is genuinely static.

For example:

const weekdays = [
  "Monday",
  "Tuesday",
  "Wednesday",
  "Thursday",
  "Friday",
];

If the list:

never changes
never gets reordered
never gets filtered
never gets inserted into
never gets deleted from

then:

key={index}

is unlikely to create an identity bug.

The important question isn't:

"Is index always bad?"

It's:

"Can the position of this item change?"

If yes, use a stable identity.

The Hidden Cost Goes Beyond Bugs

There's another reason I care about this.

Bad keys make React's reconciliation less meaningful.

React needs to answer:

"Is this the same component as before?"

Stable keys give it a reliable answer.

Bad keys force React to infer identity from position.

And position isn't identity.

This matters especially in interfaces with:

forms
animations
drag-and-drop
editable tables
shopping carts
filters
sorting
live data
virtualized lists

The more interactive the list becomes, the more important stable identity becomes.

Next.js Doesn't Change This Rule

You might be building with:

Next.js
App Router
Server Components
TypeScript
Tailwind

It doesn't matter.

Once React is rendering a dynamic list, the key still needs to represent the item's identity.

For example:

export default function Orders({
  orders,
}: {
  orders: Order[];
}) {
  return (
    <div>
      {orders.map((order) => (
        <OrderRow
          key={order.id}
          order={order}
        />
      ))}
    </div>
  );
}

That's much safer than:

{orders.map((order, index) => (
  <OrderRow
    key={index}
    order={order}
  />
))}

Here's the Mental Model I Wish More Developers Used

Don't think:

key = React requirement

Think:

key = component identity

Then the correct implementation becomes much more obvious.

If you have:

User 42

its identity is:

If it moves from position 4 to position 1, it's still User 42.

Therefore:

key={user.id}

makes sense.

But if you use:

key={index}

you're effectively saying:

"This component's identity is whatever happens to be sitting in this position."

That's usually not what you mean.

A Quick Code Review Trick

Whenever I see:

.map((item, index) => ...)

I immediately look at why index exists.

If the only reason is:

key={index}

I ask:

"Does this item have a stable ID?"

Usually the answer is yes.

Then the code becomes:

.map((item) => (
  <Component
    key={item.id}
    item={item}
  />
))

One less variable.

One better identity model.

Potentially one nasty bug avoided.

The Bug Is Often Far Away From the Key

This is why these bugs are so frustrating.

The code that creates the problem might be:

key={index}

But the symptom could appear somewhere completely different:

❌ Wrong checkbox
❌ Wrong input value
❌ Wrong animation
❌ Wrong expanded row
❌ Wrong selected item
❌ Wrong focus
❌ State apparently "moving"

So when you see strange behavior in a dynamic React list, don't only inspect the state logic.

Look at the keys.

Especially if the list can be reordered, filtered, inserted into, or deleted from.

My React Key Rule

I keep it simple:

Static list?
→ Index can be okay.

Dynamic list?
→ Use a stable ID.

User-generated data?
→ Give each item a stable ID when it's created.

Never generate keys during render.

And most importantly:

A key isn't there to make React stop complaining.

It's there to tell React:

"This thing is still the same thing."

Once you understand that, React keys stop feeling like annoying syntax and start making a lot more sense.

Have you ever had one of those React bugs where the data was completely correct but the UI was showing the wrong state?

There's a good chance the first thing worth checking was the key.

If you've encountered a weird key-related bug in production, share it below. I'd love to hear the strangest one.

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

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

Your Next.js Website Feels Slow? Check These 7 Things Before Blaming the Server

Anas Sheikh — Mon, 31 Aug 2026 14:45:41 +0000

Your Next.js application might not be slow because your server is slow.

It might be slow because you accidentally made the browser do work it never needed to do.

I've seen developers increase server resources, change hosting providers, add caching, install optimization packages, and rewrite API calls...

...only to discover the real problem was a component importing a huge library for one tiny feature.

So before you blame Vercel, your VPS, MongoDB, your API, or your internet connection, check these seven things.

Some of them take less than five minutes to find.

1. You Imported an Entire Library for One Function

This is one of the easiest performance problems to create.

Imagine you only need one utility from a package:

import _ from "lodash";

and later:

const sortedUsers = _.sortBy(users, "name");

You might not notice anything during development.

But now you're potentially bringing much more code into your application than you actually need.

Instead, prefer targeted imports when the package supports them:

import sortBy from "lodash/sortBy";

Even better, before adding a dependency, ask:

"Can I write this myself in five lines?"

Sometimes the answer is yes.

Don't install a 70 KB library to avoid writing:

const sorted = [...users].sort((a, b) =>
  a.name.localeCompare(b.name)
);

Dependencies aren't free.

Every package you add becomes part of the complexity your application has to manage.

2. You Turned a Tiny Component Into a Client Component

This one is especially important with the App Router.

You write:

"use client";

at the top of a component because you need one small interaction.

Maybe it's just a dropdown.

Maybe it's a button.

Maybe it's a small animation.

But now you've potentially moved more of your component tree into the client-side world than necessary.

For example:

"use client";

export default function Dashboard() {
  // 500 lines of UI
  // database-related data
  // charts
  // tables
  // static content
  // one dropdown
}

The problem isn't that Client Components are bad.

They aren't.

The problem is using them when you don't actually need them.

A better pattern is to keep the page server-rendered and isolate the interactive part:

Dashboard
├── Header
├── Stats
├── RevenueChart
├── RecentOrders
└── FilterDropdown ← Client Component

Instead of:

Dashboard ← Client Component
├── Header
├── Stats
├── RevenueChart
├── RecentOrders
└── FilterDropdown

Make the interactive island interactive—not the entire ocean.

3. You're Using `useEffect` to Fetch Data That Could Be Fetched on the Server

I've seen this pattern hundreds of times:

"use client";

useEffect(() => {
  fetch("/api/products")
    .then(res => res.json())
    .then(setProducts);
}, []);

It works.

But ask yourself what happens.

The browser has to:

download JavaScript
execute JavaScript
render the component
make the request
wait for the response
update state
render again

If the data doesn't require browser interaction, you may not need that entire process.

With a Server Component, you can often do:

export default async function Products() {
  const products = await getProducts();

  return (
    <ProductList products={products} />
  );
}

Now the server can retrieve the data before sending the rendered result.

This doesn't mean:

"Never fetch data in Client Components."

Client-side fetching is completely valid when the data is interactive, user-specific after hydration, frequently changing, or needs browser APIs.

The point is:

Don't automatically turn server work into browser work.

4. Your Images Are Absolutely Massive

You can have perfect React code and still ship a terrible website if you're sending 4 MB images to someone's phone.

This:

<img
  src="/hero.jpg"
  alt="Hero"
/>

isn't automatically wrong.

But Next.js provides image optimization tools for a reason.

For many use cases:

import Image from "next/image";

<Image
  src="/hero.jpg"
  alt="Hero"
  width={1200}
  height={700}
/>

gives the framework more information about how the image should be delivered.

But there's another mistake developers make:

They upload a 5000×3000 image because:

"The browser will resize it."

Sure.

But the user may still have to download the giant original.

Resize and compress your source images too.

A 4 MB hero image isn't a badge of high quality.

It's a performance problem.

5. You're Loading Everything Before the User Needs It

Imagine your dashboard contains:

charts
analytics
maps
a rich text editor
a PDF viewer
a huge data table

But the user only sees the dashboard overview first.

Why load every expensive component immediately?

Dynamic imports can help:

import dynamic from "next/dynamic";

const AnalyticsChart = dynamic(
  () => import("./AnalyticsChart")
);

Now you can defer expensive functionality when appropriate.

The same principle applies beyond components.

Ask:

"Does the user need this right now?"

If the answer is no, consider loading it later.

Performance isn't only about making code faster.

Sometimes it's about not running code yet.

6. You Have a Giant Client-Side State

This is another common one.

Developers sometimes put almost everything into global state:

users
products
orders
notifications
filters
modal state
theme
dashboard data
settings
search results
server responses

Then every part of the application subscribes to it.

Eventually you get a situation where changing one tiny value causes a surprisingly large amount of UI to update.

Global state isn't inherently bad.

But not everything needs to be global.

A useful question is:

"Who actually needs this data?"

If one component needs it, keep it local.

If a small subtree needs it, keep it close to that subtree.

If the entire application needs it, then global state makes sense.

State should live as close as possible to where it's actually used.

7. You Never Looked at Your Bundle

This is probably the biggest mistake on the list.

Developers frequently optimize code based on intuition.

They say:

"This page should be fast."

But they don't actually inspect what the browser receives.

That's backwards.

Measure first.

Then optimize.

Look at:

JavaScript bundle size
large dependencies
duplicated packages
client components
image sizes
network requests
third-party scripts
hydration work

You don't need to guess.

Your browser can tell you what it's doing.

The Performance Debugging Order I Use

When a Next.js page feels slow, I don't immediately start rewriting components.

I go in this order:

1. Network
2. Images
3. JavaScript
4. Client Components
5. Data fetching
6. Third-party scripts
7. Server/database

Why?

Because developers often jump straight to the backend.

But if the browser is downloading 3 MB of JavaScript and 8 MB of images, moving your API from a $10 VPS to a $100 server isn't going to magically fix the experience.

Find the bottleneck first.

A Simple Test You Can Do Right Now

Open your production website.

Then open:

DevTools
→ Network
→ Reload

Look at the total transferred size.

Then switch to:

DevTools
→ Performance

Record a page load.

Watch what happens.

Ask:

What takes the longest?

JavaScript?
Images?
API requests?
Rendering?
Hydration?
Third-party scripts?

That's your starting point.

Not Twitter.

Not a random optimization blog.

Not an AI-generated list of "10 Next.js tricks."

Your actual application.

The Optimization Trap

There's a dangerous stage in every developer's life where optimization becomes a hobby.

You start doing things like:

"I'll memoize this."

"I'll add another cache."

"I'll lazy-load this."

"I'll use another state library."

"I'll rewrite this component."

"I'll add another optimization package."

But nobody measured anything.

That's not optimization.

That's guessing.

A 5% theoretical improvement to something that takes 20 milliseconds doesn't matter if your biggest problem is a 4 MB image.

Performance Is About User Experience, Not Just Lighthouse Scores

A perfect Lighthouse score is nice.

But your users don't care about your Lighthouse screenshot.

They care whether:

the page appears quickly
buttons respond immediately
navigation feels smooth
content doesn't jump around
images load without destroying the layout
forms don't freeze
dashboards don't feel heavy

Performance is ultimately about how quickly your application lets someone accomplish something.

That's the metric that matters.

My 10-Minute Next.js Performance Checklist

Before I deploy a large Next.js application, I like to check:

□ Are unnecessary components marked "use client"?

□ Am I fetching static/server data in the browser?

□ Are my images compressed and appropriately sized?

□ Am I importing large libraries unnecessarily?

□ Can expensive components be dynamically loaded?

□ Is global state actually necessary?

□ Are third-party scripts slowing down the page?

□ Have I inspected the production bundle?

□ Have I tested on a slower device?

□ Did I actually measure the bottleneck?

That last question is the most important.

Did I actually measure it?

Because the slowest part of your application is often not the part you expected.

The next time someone tells you:

"Next.js is slow."

Ask them one question:

"What exactly is slow?"

The server?

The database?

The network?

JavaScript execution?

Hydration?

Images?

Rendering?

Until you know the answer, you're not debugging performance.

You're guessing.

And guessing is expensive.

What's the biggest performance mistake you've found in a Next.js project?

Mine is seeing a tiny interactive component turn an otherwise server-rendered page into a massive client-side bundle.

I'm curious what you've seen in the wild.

Drop it in the comments. 👇

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

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

Your MongoDB Login Query Might Be Vulnerable to a One-Line Bypass

Anas Sheikh — Sun, 30 Aug 2026 07:37:34 +0000

Most developers coming from a SQL background know to worry about SQL injection instinctively, string concatenation into a raw query feels obviously dangerous. MongoDB's query syntax being actual JavaScript objects creates a different, less intuitive version of the same underlying problem, and it's genuinely easy to introduce without it looking wrong at all.

The Vulnerable Version

// app/api/login/route.ts
export async function POST(request: Request) {
  const body = await request.json();

  const user = await User.findOne({
    email: body.email,
    password: body.password, // assume this is already hashed and compared correctly elsewhere
  });

  if (!user) {
    return new Response('Invalid credentials', { status: 401 });
  }

  // ... issue session
}

This looks like completely standard login logic. The vulnerability isn't in the comparison itself, it's in what body.email and body.password are actually allowed to be.

Why This Is Exploitable

MongoDB query objects use operators like $ne (not equal), $gt (greater than), and $regex directly as object keys. If body.password is a plain string, findOne compares it normally, an exact match. But if an attacker sends JSON where password is itself an object, { "$ne": null }, that's not a plain value being compared anymore, it's a MongoDB query operator being injected directly into the query.

{
  "email": "admin@example.com",
  "password": { "$ne": null }
}

{ password: { $ne: null } } translates to "find a user where password is not equal to null," which is true for essentially every real user account, since every account has some password value stored. If the attacker also knows or guesses a valid email, this query can return that user, fully bypassing the password check entirely, without ever knowing the actual password.

Why `request.json()` Makes This Worse Than You'd Expect

request.json() parses whatever JSON structure the client sends, faithfully, including nested objects. Nothing about calling .json() restricts the shape of what comes back to "an object with only string values." A client controls the entire shape of that body, and passing it straight into a Mongoose query without checking that shape first hands query-construction power directly to whoever's sending the request.

The Fix: Validate the Shape, Not Just the Presence

This is exactly why the Zod validation pattern from earlier matters here specifically, not just for user-friendly error messages, but as the actual thing preventing this class of vulnerability.

// app/api/login/route.ts
import { z } from 'zod';

const LoginSchema = z.object({
  email: z.string().email(),
  password: z.string().min(1),
});

export async function POST(request: Request) {
  const body = await request.json();
  const parsed = LoginSchema.safeParse(body);

  if (!parsed.success) {
    return new Response('Invalid credentials', { status: 401 });
  }

  const { email, password } = parsed.data; // guaranteed to be actual strings, never objects

  const user = await User.findOne({ email });
  if (!user || !(await bcrypt.compare(password, user.password))) {
    return new Response('Invalid credentials', { status: 401 });
  }

  // ... issue session
}

z.string() rejects anything that isn't genuinely a string. { "$ne": null } fails this validation immediately, safeParse returns success: false, and the request never gets anywhere near the database query at all. This closes the vulnerability completely, not by trying to detect and block MongoDB operator syntax specifically, but by guaranteeing the value's actual type before it's ever used in a query.

This Isn't Limited to Login Forms

Any Mongoose query built from unvalidated user input carries the same risk, a search endpoint, a filter parameter, anything where a request body or query string value flows into a find, findOne, or updateOne call without first being confirmed as the expected primitive type.

// ❌ A search endpoint with the same underlying vulnerability
export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const query = { name: searchParams.get('name') }; // usually a string, but not guaranteed by anything
  return Response.json(await User.find(query));
}

URL search params are always strings by default, which makes this specific example safer than the JSON body case, but the same category of risk reappears the moment a request body, rather than a URL param, is the input source, and it's worth applying the same validate-the-shape discipline everywhere user input reaches a query, not just on the endpoints that feel obviously sensitive.

The Actual Rule

Never pass a parsed request body directly into a Mongoose query without validating that every field is the primitive type you expect, string, number, whatever the field is supposed to be. Zod, or any schema validation applied before the query runs, isn't just for clean error messages, it's the actual mechanism that prevents a client from injecting a MongoDB operator where a plain value belongs.

If you have any endpoint building a Mongoose query directly from request.json() without schema validation in front of it, that's worth checking today, not eventually, this is a genuinely exploitable, well-known vulnerability class, not a theoretical edge case. Drop what you find in the comments.

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

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

Calling redirect() Inside a Suspense Boundary Doesn't Undo What Already Streamed to the Browser

Anas Sheikh — Sat, 29 Aug 2026 07:02:59 +0000

Streaming is one of the genuinely great things about the App Router, the browser can start receiving and rendering parts of a page before every single piece of data has finished loading. It also introduces a real ordering question that's easy to get wrong when auth checks and Suspense boundaries interact, and getting it wrong doesn't throw an error, it just occasionally shows a logged-out visitor a flash of something meant only for an authenticated user.

The Setup That Looks Fine

// app/dashboard/layout.tsx
export default function DashboardLayout({ children }: { children: React.ReactNode }) {
  return (
    <div className="flex">
      <Sidebar /> {/* renders immediately, not wrapped in Suspense */}
      <main>{children}</main>
    </div>
  );
}

// app/dashboard/page.tsx
import { Suspense } from 'react';

export default function DashboardPage() {
  return (
    <Suspense fallback={<DashboardSkeleton />}>
      <AuthenticatedContent />
    </Suspense>
  );
}

async function AuthenticatedContent() {
  const session = await getSession();
  if (!session) {
    redirect('/login'); // this runs, eventually
  }
  const data = await getDashboardData();
  return <Dashboard data={data} />;
}

This looks reasonable. Unauthenticated users get redirected to login. The problem is entirely about timing, not logic.

What Actually Happens, in Order

Streaming means the layout, Sidebar included, is not waiting on AuthenticatedContent to resolve before it gets sent to the browser. Sidebar has no dependency on the auth check, so React starts streaming it immediately, along with the DashboardSkeleton fallback in place of the still-loading AuthenticatedContent. Only after getSession() resolves and comes back empty does redirect('/login') actually fire, at which point the browser navigates away.

For a fast auth check, this gap is often imperceptible. For a slower one, a cold database connection, a slightly slow session lookup, there's a real window where an unauthenticated visitor sees the dashboard's sidebar, navigation, and skeleton loading state, genuine UI structure meant only for logged-in users, before the redirect actually kicks in and sends them away.

Why This Matters More Than It Sounds Like It Should

For most dashboards, a brief flash of sidebar navigation before a redirect isn't a severe security issue, the actual data never streamed, AuthenticatedContent never resolved with real information for an unauthorized visitor. But it does leak structural information, what sections exist, what the navigation looks like, sometimes feature names or areas that were meant to stay unannounced until launch. For anything more sensitive than that, a scenario where the Suspense-wrapped content itself has multiple nested pieces, some of which don't actually depend on the same auth check, the risk of a genuinely sensitive fragment slipping through before redirect increases significantly.

The Actual Fix: Check Auth Before the Suspense Boundary, Not Inside It

// app/dashboard/page.tsx
import { Suspense } from 'react';
import { redirect } from 'next/navigation';
import { getSession } from '@/lib/auth';

export default async function DashboardPage() {
  const session = await getSession(); // resolved BEFORE anything streams
  if (!session) {
    redirect('/login');
  }

  return (
    <Suspense fallback={<DashboardSkeleton />}>
      <DashboardContent userId={session.userId} />
    </Suspense>
  );
}

Moving the auth check above and outside the Suspense boundary means it resolves before React starts streaming anything from this route at all. Nothing from DashboardPage, or the content it would have rendered, reaches the browser until the redirect decision has already been made. The Suspense boundary now only wraps genuinely non-sensitive loading, the dashboard's own data fetching, not the authorization decision itself.

The Broader Rule

Authorization checks belong outside and above any Suspense boundary that gates access to something. Once a check is inside a boundary that's already streaming its fallback to the browser, you've already started sending something, and a redirect afterward is a correction, not a prevention. The layout wrapping a protected route should generally also perform its own check, since a layout renders before its children and won't itself accidentally stream protected content while waiting on an inner boundary to resolve.

// app/dashboard/layout.tsx
export default async function DashboardLayout({ children }: { children: React.ReactNode }) {
  const session = await getSession(); // checked here too, before ANY streaming starts
  if (!session) redirect('/login');

  return (
    <div className="flex">
      <Sidebar role={session.role} />
      <main>{children}</main>
    </div>
  );
}

Checking at the layout level closes the gap entirely for that route and everything nested under it, since nothing in the tree streams until this resolves.

Go Check Your Own Protected Routes

Specifically look for any redirect() call that lives inside a component wrapped in Suspense, rather than in the layout or page itself, before any Suspense boundary is reached. If your auth check is the thing inside the boundary rather than the thing gating the boundary, that's this exact pattern.

Curious whether this timing gap was something people had already run into, or whether it's as much of a surprise as it was for me the first time I actually watched it happen on a slow connection during testing. Drop your experience in the comments.

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

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

unstable_cache Can Silently Serve One User's Data to a Completely Different User

Anas Sheikh — Fri, 28 Aug 2026 09:45:35 +0000

I wrote about how force-caching a user-specific fetch can leak data across users. There's a second, less obvious way to cause almost the exact same bug using unstable_cache, and it's worth covering separately because the mistake looks completely different on the surface, even though the end result, one person's data showing up for someone else, is identical.

How unstable_cache Actually Builds Its Cache Key

unstable_cache takes three arguments, the function to cache, a key array, and options like revalidate and tags. That key array is not just a label, it's a real part of how the cache determines whether two calls should share a cached result or be treated as genuinely different.

export const getUserDashboard = unstable_cache(
  async (userId: string) => {
    await connectDB();
    return Dashboard.findOne({ userId }).lean();
  },
  ['user-dashboard'], // the actual cache key
  { revalidate: 60 }
);

Look closely at that key array. It's ['user-dashboard'], a single static string. The function itself takes userId as an argument, but userId never appears anywhere in the key. As far as the cache is concerned, every single call to this function, regardless of which userId gets passed in, shares the exact same cache entry.

What This Actually Does in Production

User A loads their dashboard. getUserDashboard('user-a-id') runs, hits the database, and the result gets cached under the key 'user-dashboard'. Sixty seconds later, User B loads their own dashboard. getUserDashboard('user-b-id') runs, but the cache doesn't check whether the argument matches anything, it just sees a valid, unexpired entry under 'user-dashboard' and returns it directly. User B gets User A's dashboard data, served instantly from cache, with no query ever hitting the database for their actual account.

No error. No warning. The function executed successfully both times, from the code's perspective. The bug is entirely in what the cache key does and doesn't distinguish between.

The Fix: Include the Actual Argument in the Key

export const getUserDashboard = unstable_cache(
  async (userId: string) => {
    await connectDB();
    return Dashboard.findOne({ userId }).lean();
  },
  ['user-dashboard'],
  { revalidate: 60 }
);

// Called like this, the userId needs to be part of what makes the cache entry unique
async function getDashboardForUser(userId: string) {
  return getUserDashboard(userId); // userId is a function argument, but NOT part of the cache key above
}

The actual fix requires either including the dynamic value directly in the key array itself, which needs to happen dynamically since the key array is evaluated once when the cached function is created, or restructuring to key by the value explicitly:

// A correct pattern: generate a uniquely-keyed cached function per user
function getCachedDashboard(userId: string) {
  return unstable_cache(
    async () => {
      await connectDB();
      return Dashboard.findOne({ userId }).lean();
    },
    ['user-dashboard', userId], // userId is now part of the actual cache key
    { revalidate: 60 }
  )();
}

Now the cache key genuinely differs per user, ['user-dashboard', 'user-a-id'] and ['user-dashboard', 'user-b-id'] are treated as entirely separate cache entries, exactly as intended.

Why This Is Easy to Miss in Review

The function signature looks completely correct. It takes userId as a parameter, uses it in the actual database query, returns the right shape of data. Nothing about reading the function's logic reveals the problem, since the bug lives entirely in the relationship between the function's arguments and the separately-defined key array, two things that are easy to mentally treat as automatically connected when they are not connected automatically at all.

The Actual Rule

Any value that makes two calls to the same cached function meaningfully different needs to be part of the cache key, explicitly. Not implied by being a function argument, not assumed because it's used inside the function body, explicitly present in the key array itself. If a cached function takes a parameter that affects which data comes back, and that parameter isn't reflected in the key, every call sharing that key range is at risk of returning the wrong caller's data.

Check Your Own unstable_cache Calls

Grep for unstable_cache across your codebase, and for each one, check whether the function's actual arguments, anything that changes what data comes back, are reflected in the key array. A cached function with a parameter and a completely static key array is exactly this bug, whether or not it's caused a visible problem yet.

grep -rn "unstable_cache" --include="*.ts" .

If you've got unstable_cache calls with parameters in production, genuinely worth checking this today rather than assuming it's fine because nothing's visibly broken yet, this bug's whole danger is that it looks completely fine until you specifically test with two different users back to back. Drop what you find in the comments.

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

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

DEV Community: Anas Sheikh

That .lean() Query Optimization Might Be Leaking Password Hashes in Your API Response

The Setup That Looks Like a Solid Security Pattern

Where This Quietly Breaks

Why This Is Genuinely Easy to Introduce

The Actual Fix: Never Rely on toJSON as Your Only Safety Net

The Broader Rule This Points To

Check Your Own API Routes

Your JWT-Based Auth Might Let a Stolen Token Outlive a Password Reset

The Core Tradeoff of Stateless Auth

What This Actually Means in Practice

Why This Surprises People

The Actual Fix: A Deliberate Revocation Layer on Top

A Simpler Partial Mitigation: Just Shorten the Expiration

The Honest Tradeoff Summary

Comparing Secrets with === in Your Next.js API Might Be Vulnerable to a Timing Attack

The Setup That Looks Completely Reasonable

Why === Leaks Timing Information

Why This Is Genuinely Harder to Exploit Than It Sounds, But Not Impossible

The Actual Fix: Constant-Time Comparison

Where This Applies in a Real Next.js Project

What This Doesn't Apply To

The Actual Checklist

Why Your MongoDB Check in Next.js Middleware Might Be Silently Failing

Why This Happens

What This Actually Looks Like

The Actual Fix: Opt Into the Node.js Runtime, or Move the Query Out

The Better Fix, Usually: Don't Query the Database in Middleware at All

The Actual Rule

Check Your Own Middleware

A Wildcard in Your next.config Image remotePatterns Might Turn Your Site Into an SSRF Proxy

The Configuration That Looks Convenient

Why This Is Actually a Real Vulnerability

The Specific, Well-Known Version of This: Cloud Metadata Endpoints

The Fix: An Actual Allowlist, Not a Wildcard

What If You Genuinely Need Broad, User-Controlled Image Sources

The Broader Rule

Check Your Own Config

Your useOptimistic UI Might Be Lying to Users When the Server Action Actually Fails

The Setup That Looks Complete

What Actually Happens When the Server Action Fails

The Fix: Actually Handle the Failure Case

A Subtler Version of the Same Gap: Partial Failure in a List

The Actual Rule

Using an Array Index as a React key Can Leak Form State Between Completely Different Items

The Setup That Looks Fine

What Actually Breaks

Why This Is So Easy to Miss in Testing

The Fix: Key by Something Stable and Unique to the Item

Where This Specifically Bites Harder: AnimatePresence

The Actual Rule

Stop Using Array Index as a React Key. The Bug You Create Might Not Be Where You Think.

What React Actually Uses a Key For

The Classic Example: A Checkbox

Why It Doesn't Happen Immediately

Sorting Makes It Even More Obvious

The Fix Is Usually Ridiculously Simple

"But My Data Doesn't Have an ID"

What About crypto.randomUUID()?

There Is One Situation Where Index Keys Are Fine

The Hidden Cost Goes Beyond Bugs

Next.js Doesn't Change This Rule

Here's the Mental Model I Wish More Developers Used

A Quick Code Review Trick

The Bug Is Often Far Away From the Key

My React Key Rule

Your Next.js Website Feels Slow? Check These 7 Things Before Blaming the Server

1. You Imported an Entire Library for One Function

2. You Turned a Tiny Component Into a Client Component

3. You're Using useEffect to Fetch Data That Could Be Fetched on the Server

4. Your Images Are Absolutely Massive

5. You're Loading Everything Before the User Needs It

6. You Have a Giant Client-Side State

7. You Never Looked at Your Bundle

The Performance Debugging Order I Use

A Simple Test You Can Do Right Now

The Optimization Trap

Performance Is About User Experience, Not Just Lighthouse Scores

My 10-Minute Next.js Performance Checklist

Your MongoDB Login Query Might Be Vulnerable to a One-Line Bypass

What About `crypto.randomUUID()`?

3. You're Using `useEffect` to Fetch Data That Could Be Fetched on the Server

Why `request.json()` Makes This Worse Than You'd Expect