Remix security checklist

Remix v2 or React Router 7?

React Router 7 superseded Remix. Start new apps on React Router 7. Existing Remix v2 apps can stay on Remix until you migrate; the security checklist is the same, but the package names differ.

Loaders and actions still run on the server. Cookies, CSRF, and header rules still apply. The rest of this article uses Remix v2 names (LoaderFunctionArgs, @remix-run/node). On React Router 7, swap the types for Route.LoaderArgs and import Arcjet from @arcjet/react-router.

Use this checklist. Each item is a control you can verify.

• Patch and lock dependencies.
• Keep side effects out of module scope.
• Keep secrets in .server.ts modules and out of loader returns.
• Sign cookies and authorize in every loader and action.
• Mutate only in actions, never in loaders.
• Set security headers in entry.server (and handleDataRequest).
• Validate form data, query params, and cookies with a schema.
• Do not write user uploads to your app server disk.

The web app security checklist covers abuse that appears after the app is live. The Next.js security checklist is the parallel guide if you run both frameworks.

How do you keep Remix dependencies safe?

Commit the lockfile. Review updates weekly. Dependabot or Renovate plus npm audit in CI is the minimum.

JavaScript packages change often. Skipping several major versions makes a later CVE an emergency. Treat install scripts, new network access, and ownership changes as review events. Prefer a short function you maintain over a trivial dependency.

Why must Remix avoid module-scope side effects?

The Remix compiler strips server-only exports from the browser bundle. That only works if sensitive work stays inside loader and action. Code that runs when the module is imported can execute too early or leak into the client graph.

1
import { auth } from "../auth.server";
2
import type { LoaderFunctionArgs } from "@remix-run/node";
3

4
// Dangerous: runs at import time.
5
const authStatus = auth.verifySession();
6

7
export async function loader({ request }: LoaderFunctionArgs) {
8
  return Response.json({ status: authStatus });
9
}

Move the call into the loader:

1
import { auth } from "../auth.server";
2
import type { LoaderFunctionArgs } from "@remix-run/node";
3

4
export async function loader({ request }: LoaderFunctionArgs) {
5
  const authStatus = await auth.verifySession(request);
6
  return Response.json({ status: authStatus });
7
}

Anything you return from a loader is visible to the client, even if a component never renders it. Treat loader JSON as a public API.

How should Remix environment variables be handled?

Put secret access in *.server.ts files. Those modules never ship to the browser. Read process.env inside a loader or action. Do not put a secret on window.ENV.

window.ENV is a convenience for public values such as a marketing site URL. If a value can mint a session or open a database, it does not belong there.

Prefer a secrets manager in production. Child processes inherit environment variables, and the values often appear in crash dumps.

How do you authenticate and authorize Remix routes?

Create cookies with createCookie or a session storage helper. Store cookie definitions in a *.server.ts file. Remix signs cookies when you provide secrets. Keep those secrets unguessable and rotate by putting the new secret first in the array so old cookies still decode.

Session storage options include cookie sessions, file sessions, Workers KV, and DynamoDB. Read and write the session in loaders and actions. Do not trust a client-supplied user ID.

Authorization is a second check. A valid session is not permission to edit another team's project. Look up the object with the caller's tenant or owner constraint before you return or mutate it.

You can use Auth.js, Clerk, Better Auth, or a session you control. The important part is that every loader and action that touches private data performs the check.

How do you prevent CSRF in Remix?

Browsers that honor SameSite=Lax (Remix's cookie default) block most cross-site cookie sends on POST. That is not enough if you accept mutations from GET or from a loader.

Never log out, change email, or update a password in a loader. Put every mutation in an action. A loader that mutates is a CSRF bug.

Add an anti-CSRF token for sensitive actions if you need defense beyond SameSite. remix-utils includes CSRF helpers, safe redirects, and CORS utilities. Validate the redirect target against an allowlist so an open redirect cannot bounce users to a phishing page.

Where should Remix set security headers?

Route headers exports do not merge the way most people expect. A child route replaces parent headers unless you merge them yourself. A child Cache-Control can silently weaken a parent policy.

Set security headers in entry.server so they apply to document requests. For data requests, set them in handleDataRequest.

1
function applySecurityHeaders(headers: Headers) {
2
  headers.set("X-Content-Type-Options", "nosniff");
3
  headers.set("Referrer-Policy", "strict-origin-when-cross-origin");
4
  headers.set("X-Frame-Options", "SAMEORIGIN");
5
  headers.set(
6
    "Content-Security-Policy",
7
    "default-src 'self'; frame-ancestors 'self'",
8
  );
9
  headers.set(
10
    "Strict-Transport-Security",
11
    "max-age=31536000; includeSubDomains",
12
  );
13
  headers.set("Permissions-Policy", "camera=(), microphone=(), geolocation=()");
14
}
15

16
export function handleDataRequest(response: Response) {
17
  applySecurityHeaders(response.headers);
18
  return response;
19
}

If Remix sits behind Express, Helmet can set the same headers at the HTTP layer. Still set them in entry.server if some requests never hit that Express middleware.

How do you validate Remix form data?

React escapes string children. That does not protect href, style, dangerouslySetInnerHTML, Markdown rendering, or SQL.

Validate request.formData(), query strings, and session fields with Zod or Valibot in the action or loader. Return field errors with 400 or 401. Do not trust the HTML required attribute.

1
import type { ActionFunctionArgs } from "@remix-run/node";
2
import { z } from "zod";
3

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

9
export async function action({ request }: ActionFunctionArgs) {
10
  const parsed = loginSchema.safeParse(
11
    Object.fromEntries(await request.formData()),
12
  );
13
  if (!parsed.success) {
14
    return Response.json(
15
      { errors: parsed.error.flatten().fieldErrors },
16
      { status: 400 },
17
    );
18
  }
19
  // authenticate parsed.data
20
}

Use the same schema on the client for faster feedback if you want, but keep the server parse as the source of truth.

How should Remix handle file uploads?

Do not persist user files on the application server disk. Remix upload helpers can filter by size and type, but content-type is not proof of content. A renamed executable will pass a naive MIME check.

Send uploads to object storage (S3 or equivalent) with a short-lived, scoped credential. Scan the object after upload if other users can download the file. Serve downloads through a handler that authorizes the object, not through a public bucket listing.

How do you screen Remix requests at runtime?

Framework hygiene does not stop credential stuffing or a scraped loader. Screen the request in the loader or action before you hit the database.

Remix v2 with @arcjet/remix v1:

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

4
const aj = arcjet({
5
  key: process.env.ARCJET_KEY!,
6
  rules: [
7
    shield({ mode: "LIVE" }),
8
    detectBot({ mode: "LIVE", allow: [] }),
9
    slidingWindow({ mode: "LIVE", interval: 60, max: 20 }),
10
  ],
11
});
12

13
export async function action(args: ActionFunctionArgs) {
14
  const decision = await aj.protect(args);
15

16
  if (decision.isDenied()) {
17
    if (decision.reason.isRateLimit()) {
18
      throw new Response("Too many requests", { status: 429 });
19
    }
20
    throw new Response("Forbidden", { status: 403 });
21
  }
22

23
  // validate, authenticate, then mutate
24
}

React Router 7 uses the same rules. Import from @arcjet/react-router and pass Route.ActionArgs (or Route.LoaderArgs) to protect().

Allow CATEGORY:SEARCH_ENGINE on public document loaders if you want crawlers. Keep allow: [] on login and password-reset actions.

What should you do after this checklist?

Confirm each item against one sensitive route: login, password reset, and a mutation that changes account email. Then apply the web app security checklist for abuse that only shows up under real traffic.