How to secure login pages

Why do login pages need their own controls?

A login page is an unauthenticated endpoint that, on success, issues a session. Attackers try passwords, replay leaked credentials, inject SQL into the username field, and steal or fix sessions. The same HTML form is the target for all four.

This article applies to any server-rendered or API-backed login. Examples use Next.js App Router and @arcjet/next v1. The same rule shapes work in Remix, Nuxt, and NestJS. For framework hygiene around the form, see the Next.js security checklist and the web app security checklist.

Which login threats should you plan for?

How do you detect login attacks?

Log every login attempt with a timestamp, username (or a hash of it), client IP, success or failure, and a correlation ID. Do not log the password or the full cookie.

Pino, Winston, and Bunyan all emit JSON you can ship to Grafana, Datadog, or the Elastic Stack. For live alerts, export a counter to Prometheus with prom-client:

1
import { Counter } from "prom-client";
2

3
const failedLogins = new Counter({
4
  name: "failed_login_attempts",
5
  help: "Failed login attempts",
6
  labelNames: ["ip"],
7
});
8

9
const loginAttempts = new Counter({
10
  name: "login_attempts_total",
11
  help: "Login attempts by username and IP",
12
  labelNames: ["username", "ip"],
13
});
14

15
failedLogins.inc({ ip });
16
loginAttempts.inc({ username, ip });

Alert when one IP fails many times, when one IP tries many usernames, or when failures rise across the fleet. That signal is how you distinguish brute force from stuffing. It is not a substitute for blocking; it tells you when to tighten a limit or revoke sessions.

How do you rate limit login attempts?

A fixed window of 5 attempts per 10 minutes is a reasonable starting point for a password form. Key on IP before authentication. After a successful identification of the account (even on failure), also key on the username so a botnet cannot spray one account from many addresses without a second limit.

1
import arcjet, { fixedWindow } from "@arcjet/next";
2
import { setRateLimitHeaders } from "@arcjet/decorate";
3
import { NextResponse } from "next/server";
4

5
const aj = arcjet({
6
  key: process.env.ARCJET_KEY!,
7
  rules: [
8
    fixedWindow({
9
      mode: "LIVE",
10
      window: "10m",
11
      max: 5,
12
    }),
13
  ],
14
});
15

16
export async function POST(req: Request) {
17
  const decision = await aj.protect(req);
18
  const headers = new Headers();
19
  setRateLimitHeaders(headers, decision);
20

21
  if (decision.isDenied() && decision.reason.isRateLimit()) {
22
    return NextResponse.json(
23
      { error: "Too many login attempts. Try again later." },
24
      { status: 429, headers },
25
    );
26
  }
27

28
  // validate, then authenticate
29
}

Return 429 with Retry-After or draft RateLimit headers so a legitimate user knows to wait. Do not tell the client whether the username exists.

Add MFA after a successful password check. Increase delay or drop max after repeated failures from the same IP. Enforce a password policy (length, no breached passwords). OWASP documents the baseline.

How do you stop credential stuffing?

Stuffing uses real passwords from other breaches. Rate limits alone fail when the bot stays under the ceiling and rotates IPs. Deny automated clients on the login route.

1
import arcjet, { detectBot, fixedWindow } from "@arcjet/next";
2
import { NextResponse } from "next/server";
3

4
const aj = arcjet({
5
  key: process.env.ARCJET_KEY!,
6
  rules: [
7
    fixedWindow({
8
      mode: "LIVE",
9
      window: "10m",
10
      max: 5,
11
    }),
12
    detectBot({
13
      mode: "LIVE",
14
      allow: [],
15
    }),
16
  ],
17
});
18

19
export async function POST(req: Request) {
20
  const decision = await aj.protect(req);
21

22
  if (decision.isDenied()) {
23
    if (decision.reason.isRateLimit()) {
24
      return NextResponse.json(
25
        { error: "Too many login attempts. Try again later." },
26
        { status: 429 },
27
      );
28
    }
29
    if (decision.reason.isBot()) {
30
      return NextResponse.json(
31
        { error: "Automated access denied" },
32
        { status: 403 },
33
      );
34
    }
35
    return NextResponse.json({ error: "Forbidden" }, { status: 403 });
36
  }
37

38
  // validate, then authenticate
39
}

detectBot({ allow: [] }) is the v1 allow-list form. It denies every detected bot. Do not use the old block: ["AUTOMATED"] option; that API is gone.

Check passwords against a breach corpus (Have I Been Pwned's k-anonymity API or a local list). Require MFA for privileged roles. Notify the user on a login from a new device.

How do you prevent SQL injection on login?

Never build a query by concatenating the username or password. This is the classic bypass:

1
SELECT * FROM users WHERE username = 'admin' --' AND password = 'x'

Use a parameterized query or an ORM that always parameterizes:

1
const res = await client.query(
2
  `SELECT id, password_hash FROM users WHERE username = $1`,
3
  [username],
4
);

Compare the password with a slow hash (argon2id or scrypt), not with SQL crypt in a string you control from the client. Validate the body first:

1
import { z } from "zod";
2

3
const loginSchema = z.object({
4
  username: z.string().min(3).max(50),
5
  password: z.string().min(8).max(128),
6
});
7

8
const parsed = loginSchema.safeParse(await req.json());
9
if (!parsed.success) {
10
  // A malformed body is a 400, not an unhandled throw and a 500.
11
  return Response.json({ error: "Invalid credentials" }, { status: 400 });
12
}
13
const { username, password } = parsed.data;

Grant the app role SELECT (and whatever else it needs) on users, not SUPERUSER. Enable row-level security if the same role later reads tenant data. Return a generic "Invalid credentials" to the client. Log the real database error only on the server.

Shield analyzes requests for injection and XSS patterns. Add it beside the rate limit and bot rules:

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

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

Shield is a pattern filter. It does not replace parameterized queries.

How do you keep login sessions from being stolen?

After a successful password check, issue a new session ID. Do not reuse an anonymous ID (that is session fixation). Generate the ID with crypto.randomBytes or your framework's session helper, not with a sequential integer.

Set the cookie as HttpOnly, Secure in production, SameSite=strict or Lax (Lax if you need top-level GET navigation to send it), and a bounded Max-Age. Implement an idle timeout (for example 15 minutes without activity) and an absolute timeout (for example 2 hours).

Rotate the session again after a privilege change (password change, MFA enrollment, role upgrade). Invalidate the old ID.

Store a CSRF token in the server session and require it on POST. For Next.js App Router, prefer the framework's origin check plus a double-submit or session token; do not copy a Pages Router getSession snippet that no longer matches your stack.

Set a Content Security Policy that disallows inline scripts you do not need. XSS is the usual way to read a cookie that is not HttpOnly or to fire requests as the user. The Next.js security checklist covers header setup.

IP binding (reject the session if the client IP changes) helps on high-risk accounts and hurts users on mobile networks. Use it for admin sessions, or treat an IP change as a step-up MFA prompt rather than a hard logout for ordinary users.

What does a complete login handler look like?

Order of operations:

1. Screen the request (rate limit, bots, shield).
2. Parse and validate the body.
3. Authenticate with a parameterized lookup and a password hash.
4. On success, rotate the session, set a tight cookie, and issue a CSRF token.
5. On failure, increment metrics, return a generic error, and do not leak whether the user exists.

Keep the same order in Remix actions, Nuxt server routes, and NestJS controllers. The web app security checklist extends these controls to signup, reset, and other costly anonymous flows.