If you search for “Next.js security checklist” or “Remix security best practices,” you’ll find solid guidance. Most framework teams do a good
If you search for “Next.js security checklist” or “Remix security best practices,” you’ll find solid guidance. Most framework teams do a good job documenting how to use their tools safely: how to handle authentication, where secrets should live, which APIs run on the server, and which don’t.
That guidance is necessary. It’s also out of scope.
Once an application is in production, most security issues don’t come from misusing framework features. They come from abuse. Automated traffic. APIs being called in ways you didn’t expect. Business logic that works perfectly for real users but falls apart at scale.
This is where teams start asking the same questions, regardless of which framework they’re using.
This post isn’t a replacement for framework-specific security guides. It’s a higher-level checklist for evaluating whether a web application is resilient to real-world abuse. If you’re building with Next.js or Remix, start with our framework-specific security checklists. They cover how to use the framework safely and correctly. This post assumes you’ve already followed those guides and focuses on what tends to break later, once an application is live and facing real traffic and abuse.
Framework security checklists focus on things that can be documented generically: authentication patterns, headers, data handling, configuration, and deployment defaults. They are designed to help teams use the framework correctly. They stop where application-specific behavior begins, because abuse and misuse look different for every app.
As more logic moves server-side, through route handlers, loaders, actions, and APIs, that gap becomes more obvious. The questions below are the ones teams usually discover after something goes wrong.
Most web applications assume that requests come from people. Bots break that assumption. If you don’t know how much of your traffic is automated, you’re already operating blind. Bots don’t just scrape content. They submit forms, brute-force credentials, enumerate APIs, and probe application behavior.
At a minimum, teams should be able to answer:
IP blocking alone is rarely enough. Automated traffic increasingly looks like normal users, which is why bot detection needs to operate at the application boundary, where behavior and intent are visible.
This is the layer Arcjet focuses on: evaluating traffic quality at the application boundary, not just at the network edge.
Most web apps today are API-driven, even when they look like traditional websites. Every button click triggers a request. Every page load hits multiple endpoints. Rate limiting is usually added eventually, but often in a generic way that doesn’t reflect real usage, be sure to ask:
API abuse is less about volume and more about shape. A few valid requests in the wrong place can be more damaging than a flood of obvious junk traffic. Effective rate limiting needs application context, not just request counts.
Many attacks don’t violate any technical constraints. They exploit business assumptions. Signup flows that assume humans move slowly. Free trials that assume honest usage. Checkout logic that assumes a single user at a time. These attacks are hard to detect because every request is valid. The only signal is behavior over time, like:
This is not something a framework can solve for you. It has to live alongside application logic where context and intent exist.
Input validation is table stakes, but validation alone doesn’t prevent waste. Malformed requests, oversized payloads, and abusive traffic can still consume CPU, memory, and downstream resources before they fail. In serverless and usage-based environments, that cost adds up quickly. Focus on:
Stopping abuse early is as much about reliability as it is about security.
Security controls without visibility create false confidence. If you can’t see when traffic patterns change, which endpoints are being targeted, or whether protections are triggering, you’re guessing. That makes incidents harder to diagnose and fixes harder to validate. Things like:
Security metrics should be something developers can use, not just something that exists.
One of the fastest ways security gets bypassed is friction. If a tool doesn’t work with serverless or edge runtimes, you have a gap. If it requires heavy configuration, it gets postponed. If it doesn’t integrate cleanly with frameworks, it gets bolted on awkwardly with potential for error. It’s important to know:
Security that fits naturally into the stack is more likely to stay enabled.
Framework security guides help teams use their tools correctly. They are not designed to handle misuse that emerges only after an application is live.
That gap sits closer to your code, where real traffic, real users, and real behavior intersect.
Arcjet is built to operate directly inside the app layer. It gives teams visibility into traffic quality and control over API usage and critical application flows, using context that only exists inside the application itself.
For teams building with Next.js, Remix, Firebase, and Nuxt, this makes it possible to address abuse and misuse without pushing security concerns down to infrastructure or bolting them on after the fact.
Get the full posts by email every week.
