A Broken Button Is Obvious. A Broken Auth Check Isn't.

Chukwuemeka Andre Ozomma — Tue, 18 Aug 2026 13:51:11 +0000

Here's a bug that will pass code review, pass a quick manual test, and sit in production for months before anyone notices — because it only breaks on the one input nobody thinks to try.

Say you're building a delete endpoint. A user should only be able to delete their own resource — a recipe, a document, a post, doesn't matter. The obvious approach:

js
export async function DELETE(request, { params }) {
  const { id } = await params;
  const recipe = await prisma.recipe.findUnique({ where: { id: Number(id) } });

  const session = await auth();

  if (recipe.userId !== session?.user?.id) {
    return Response.json({ error: "Forbidden" }, { status: 403 });
  }

  await prisma.recipe.delete({ where: { id: Number(id) } });
  return Response.json({ success: true });
}`

Test it with a real recipe ID you own — works. Test it with someone else's recipe ID — correctly forbidden. Ship it.

Now request a recipe ID that doesn't exist.

recipe comes back null. The very next line — recipe.userId — throws, because you can't read a property off null. In a lot of setups, that unhandled exception doesn't cleanly return a 403 or a 404. Depending on your error handling upstream, it can surface as a raw 500, sometimes with a stack trace, sometimes with enough detail to tell an attacker things about your schema they shouldn't be able to see. And if your error handling is too forgiving in the wrong direction, malformed input can slip past the check that was supposed to stop it — the check never even ran, because the code crashed before reaching it.

Either way: the ownership check silently didn't happen. Not because the logic was wrong. Because of what order things ran in.

Why this is worse than it looks

The dangerous part isn't that this crashes. Crashes get noticed. The dangerous part is how easy it is to write a slightly different version of this same mistake that doesn't crash — it just quietly returns the wrong answer instead. The moment your authorization check depends on data that might not exist yet, you've made "does this check even run" conditional on something you didn't intend to make it conditional on.

A broken button is obvious the second you click it. A broken authorization check can be technically "working" for every test case you happened to think of, and wrong for the one you didn't.

The fix is about order, not logic

js
export async function DELETE(request, { params }) {
  const { id } = await params;
  const session = await auth();

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

  const recipe = await prisma.recipe.findUnique({ where: { id: Number(id) } });

  if (!recipe) {
    return Response.json({ error: "Not found" }, { status: 404 });
  }

  if (recipe.userId !== session.user.id) {
    return Response.json({ error: "Forbidden" }, { status: 403 });
  }

  await prisma.recipe.delete({ where: { id: Number(id) } });
  return Response.json({ success: true });
}

Same logic. Same three questions being asked. The only thing that changed is the order: check who's asking, then check whether the thing they're asking about even exists, then check whether they're allowed to touch it. Every guard clause runs before anything that could be null gets touched.

The general rule I keep coming back to: authorization code should be readable top to bottom as a sequence of gates, each one safe to evaluate no matter what came before it. If a later check depends on data a null case could have skipped past, you don't have three independent checks — you have one check with a hole in it.

Where this actually bites

This exact shape of bug shows up constantly, not just in delete routes:

An "is this user an admin" check that runs after a database call that assumed the user already exists
A permission check on a field that's undefined for legacy records created before that field existed
A check that correctly blocks the UI button from rendering, while the actual API route behind it has no equivalent server-side check at all — the client-side gate was doing all the work, and it's trivial to bypass by just calling the endpoint directly

That last one is worth sitting with for a second: hiding a button is not authorization. If the check only exists in the frontend, the "check" is a UI suggestion, not a security boundary.

The habit worth building

When you're reviewing any authorization code — your own, a teammate's, or something AI just generated for you — trace it in this order:

- Is identity checked first, before anything else runs?
- Does the code correctly handle the resource not existing, before it tries to check ownership of that resource?
- Is the check enforced on the server, not just hidden in the UI?

If you can't answer all three by reading the function top to bottom, it's worth another look — regardless of how confidently it was written, by you or by an AI tool.

I write about backend patterns like this one in more depth in AI-Assisted Backend Development — happy to dig into any specific edge case in the comments if it's useful.

Build First. Understand What You Build. Then Use AI to Build Faster.

Chukwuemeka Andre Ozomma — Fri, 14 Aug 2026 02:30:57 +0000

A few months ago I noticed something that bugged me enough to eventually write a book about it.

AI coding tools are genuinely good now. Copilot, Claude, Cursor — you can describe a feature and watch working code appear in seconds. That's not hype, it's just true. But I kept running into the same pattern, in my own work and in conversations with other developers: there's a growing gap between being able to generate code and being able to tell whether that code is actually good.

Not broken — broken is easy. It throws an error, you notice, you fix it. I mean the quieter failure mode: code that runs, looks reasonable, and is subtly wrong in a way you only catch if you already understand what "right" looks like. An unindexed database column that's fine at 10 rows and falls over at 100,000. An authorization check that works for the happy path and quietly leaks data the moment a null slips through. A component with three pieces of state where one would do.

AI won't stop you from shipping any of that. It'll happily generate it, confidently, in about four seconds.

So when I sat down to write a frontend development book, I made a deliberate call that I think goes against how most "AI coding" content is currently being written: no AI at all until the fundamentals are solid. HTML, CSS, JavaScript, React, Next.js — built by hand, understood completely, mistakes made and debugged the slow way. Only once that foundation exists does the book bring in Copilot, Claude, and Cursor — and even then, the framing isn't "here's how to prompt your way to a finished app." It's "here's how to read what the AI gives you and decide, yourself, whether it's actually right."

The line I kept coming back to while writing it:

Build first. Understand what you build. Then use AI to build faster.

I didn't want a reader finishing the book thinking "now I know how to get AI to build things for me." I wanted them finishing it thinking "now I understand how these things get built, and I can use AI without handing over my ability to think and decide as a developer."

The book's capstone is a small app — a Recipe Box — built three separate times: once by hand with vanilla HTML/CSS/JS, once in React, once in Next.js. Watching the same problem solved three different ways ended up being a better teacher than I expected going in. It makes the differences between the tools obvious instead of abstract.

I just finished a second book that continues the same project into the backend — servers, databases, authentication, real deployment — applying the same rule. Backend mistakes are quieter and more expensive than frontend ones, so if "understand before you accelerate" matters anywhere, it matters there most.

I'm genuinely curious how other developers here are navigating this. Are you teaching or learning AI-assisted development in a similar fundamentals-first order, or has it worked better for you to learn the tools alongside the basics from day one? I don't think there's one obviously correct answer yet — it's early enough that we're all sort of figuring it out in public.

I wrote about this in more depth in a two-book series if anyone wants to dig further — Frontend and Backend, each walking through the same idea from a different layer of the stack. Would love to hear how this lands with people living this exact tension day to day.

DEV Community: Chukwuemeka Andre Ozomma

A Broken Button Is Obvious. A Broken Auth Check Isn't.

Build First. Understand What You Build. Then Use AI to Build Faster.