Web app security checklist

What is the web app security checklist?

Framework guides tell you how to use Next.js, Remix, or Nuxt safely: where secrets live, which functions run on the server, how to set cookies. This checklist starts after that work. It asks whether the live app can survive automated traffic, unexpected API use, and business-logic abuse.

Use the framework guides first:

• Next.js security checklist
• Remix security checklist
• Secure a NestJS application
• Secure login pages

Then work through these six questions. Each one is a control you can verify in production, not a slogan.

• Can you tell human traffic from automated traffic on each sensitive route?
• Do rate limits match how the route is used (user, token, or IP; anonymous vs authenticated)?
• Which business flows would hurt you if they were automated with valid requests?
• Are invalid or oversized requests rejected before they reach expensive code?
• Can you see when abuse started, which route was hit, and whether a control fired?
• Do the controls run where the request is handled, including serverless and edge?

Why do framework security guides stop here?

Framework docs can be generic. They cover headers, auth patterns, and configuration. They cannot know that your trial signup is expensive, that your search endpoint dumps the catalog, or that anonymous users share a NAT.

As more logic moves into Route Handlers, loaders, actions, and server routes, that gap gets wider. Abuse looks like a valid user doing a valid thing too often, or from the wrong client. The questions below are the ones teams usually ask after the first incident.

How do you detect automated traffic?

Most apps assume a browser. Bots submit forms, stuff credentials, enumerate IDs, and scrape APIs. IP denylists fail when attackers rotate addresses and when real users share a network.

You should be able to answer:

• What share of traffic on login, signup, and search is automated?
• Which routes are hit by bots?
• Can you deny abusive automation without blocking a search crawler you want?

Bot detection belongs next to the handler, where you know the route and whether a session exists. A public marketing page can allow CATEGORY:SEARCH_ENGINE. A login action should allow none.

Next.js Route Handler:

1
import arcjet, { detectBot, shield } from "@arcjet/next";
2

3
const aj = arcjet({
4
  key: process.env.ARCJET_KEY!,
5
  rules: [shield({ mode: "LIVE" }), detectBot({ mode: "LIVE", allow: [] })],
6
});
7

8
export async function POST(req: Request) {
9
  const decision = await aj.protect(req);
10
  if (decision.isDenied()) {
11
    return Response.json({ error: "Forbidden" }, { status: 403 });
12
  }
13
}

Remix action (Remix v2; React Router 7 uses @arcjet/react-router):

1
import arcjet, { detectBot, shield } from "@arcjet/remix";
2
import type { ActionFunctionArgs } from "@remix-run/node";
3

4
const aj = arcjet({
5
  key: process.env.ARCJET_KEY!,
6
  rules: [shield({ mode: "LIVE" }), detectBot({ mode: "LIVE", allow: [] })],
7
});
8

9
export async function action(args: ActionFunctionArgs) {
10
  const decision = await aj.protect(args);
11
  if (decision.isDenied()) {
12
    throw new Response("Forbidden", { status: 403 });
13
  }
14
}

Nuxt server route:

1
import arcjetNuxt, { detectBot, shield } from "#arcjet";
2

3
const arcjet = arcjetNuxt({
4
  rules: [shield({ mode: "LIVE" }), detectBot({ mode: "LIVE", allow: [] })],
5
});
6

7
export default defineEventHandler(async (event) => {
8
  const decision = await arcjet.protect(event);
9
  if (decision.isDenied()) {
10
    throw createError({ statusCode: 403, statusMessage: "Forbidden" });
11
  }
12
});

How should you rate limit APIs?

A page view is several API calls. A generic per-IP limit either blocks an office or ignores a distributed bot. Ask:

• Is the limit keyed on user, API token, or IP?
• Do anonymous and authenticated callers have different ceilings?
• Can one user trigger an expensive export or AI call in a tight loop?

Abuse is often shape, not volume. Five valid checkout attempts can cost more than a thousand junk GETs. Put a tighter limit on the costly operation. The rate limiting guide compares fixed window, sliding window, and token bucket.

Next.js, keyed on a user characteristic once you have a session:

1
import arcjet, { slidingWindow } from "@arcjet/next";
2

3
const aj = arcjet({
4
  key: process.env.ARCJET_KEY!,
5
  characteristics: ["userId"],
6
  rules: [slidingWindow({ mode: "LIVE", interval: 60, max: 10 })],
7
});
8

9
export async function POST(req: Request) {
10
  const userId = "user-123"; // from your session
11
  const decision = await aj.protect(req, { userId });
12
  if (decision.isDenied()) {
13
    return Response.json({ error: "Too many requests" }, { status: 429 });
14
  }
15
}

Remix loader, IP-keyed before login:

1
import arcjet, { fixedWindow } from "@arcjet/remix";
2
import type { LoaderFunctionArgs } from "@remix-run/node";
3

4
const aj = arcjet({
5
  key: process.env.ARCJET_KEY!,
6
  rules: [fixedWindow({ mode: "LIVE", window: "1m", max: 30 })],
7
});
8

9
export async function loader(args: LoaderFunctionArgs) {
10
  const decision = await aj.protect(args);
11
  if (decision.isDenied()) {
12
    throw new Response("Too many requests", { status: 429 });
13
  }
14
  return null;
15
}

Nuxt, token bucket for a variable-cost route:

1
import arcjetNuxt, { tokenBucket } from "#arcjet";
2

3
const arcjet = arcjetNuxt({
4
  rules: [
5
    tokenBucket({
6
      mode: "LIVE",
7
      refillRate: 5,
8
      interval: 10,
9
      capacity: 10,
10
    }),
11
  ],
12
});
13

14
export default defineEventHandler(async (event) => {
15
  const decision = await arcjet.protect(event, { requested: 5 });
16
  if (decision.isDenied()) {
17
    throw createError({ statusCode: 429, statusMessage: "Too Many Requests" });
18
  }
19
});

How do you protect application logic from misuse?

Many attacks never fail validation. They automate a flow you designed for a human: trial signups, inventory holds, password resets, preview renders.

List the actions that become expensive or harmful when automated. Put a product rule next to the code that performs them: one trial per verified email, one hold per account, a cooldown on password reset. Schema validation cannot express "this user already reserved the last seat."

Login and signup are the usual first targets. Apply the tighter controls in secure login pages.

How do you stop bad requests before they cost money?

A 400 after you have parsed a 20 MB body, called the ORM, and invoked a model still costs you. Reject early:

• Enforce body and file size limits at the framework or host.
• Validate the schema before any database or provider call.
• Time out and cancel downstream work when the client disconnects.
• Fail closed on login, payment, and export if the security dependency is down; fail open only where availability matters more than abuse.

That last one needs code, because the default is fail-open and it is easy to miss. When Arcjet cannot reach the service, the decision comes back as an error, and isDenied() is false for it, so a handler that only branches on isDenied() lets the request through. Every other sample on this page does exactly that, which is the right default for a public read. On the routes above, add the second branch:

1
export async function POST(req: Request) {
2
  const decision = await aj.protect(req);
3

4
  if (decision.isErrored()) {
5
    // Availability of the checkout matters less than charging the wrong card.
6
    console.error("Arcjet decision failed", decision.reason.message);
7
    return Response.json({ error: "Service unavailable" }, { status: 503 });
8
  }
9

10
  if (decision.isDenied()) {
11
    return Response.json({ error: "Forbidden" }, { status: 403 });
12
  }
13

14
  // Charge the card.
15
}

Shield-style request analysis helps when the payload looks like injection or XSS. It does not replace a size limit or a parameterized query.

What should you monitor for abuse?

A control you cannot see will drift. Log the route, a request or decision ID, the conclusion, and the reason code. Do not log passwords, tokens, or raw bodies.

Alert on:

• A step change in denied requests on one route
• Failed logins across many accounts from one client
• A rise in 429s that does not match a release
• Exports or AI calls far above the daily baseline

Give each alert an owner and a response: tighten a rule, rotate a credential, or take one route offline without taking the site down.

How do you keep security in the request path?

If a tool does not run on your serverless or Node host, you have a gap. If it takes a week to configure, it ships after the feature. Prefer a library you call in the handler so the rule sits next to the code it protects.

That is true for Next.js, Remix, Nuxt, and NestJS. The SDK package name changes; the habit does not: decide before you do the work, branch on deny, and keep the rule in source control.