Remix v2 Meta, Sessions, Auth, and CSRF Code Review

Reviews Remix v2 meta/SEO, session, auth-gate, and CSRF code paths. Loaded by the umbrella review-remix-v2 reviewer when a diff touches any of: meta/links exports, root.tsx, *.server.ts session/cookie modules, loaders/actions reading or writing session, or \x3CForm>/useFetcher mutations.

See beagle-remix-v2:remix-v2-meta-sessions for canonical patterns.

Quick Reference

Highest-stakes detection — call out first: v1 meta object shape (return { title, description }) in a v2 codebase. It typechecks, but the runtime ignores it and the page renders with no title and no meta tags. Grep every export const meta and confirm the return value starts with [, not {.

Review Checklist

• meta returns MetaDescriptor[] (array starts with [), NOT the v1 object shape
• OG / Twitter tags use { property, content }, NOT v1 shorthand { "og:title": "..." }
• No document.title = "..." or useEffect(() => { document.title = ... }) — meta is set via the meta export
• root.tsx includes \x3CMeta /> and \x3CLinks /> inside \x3Chead>
• Child meta that wants parent values uses matches.flatMap((m) => m.meta ?? [])
• meta null-guards data (loader may not have run / returned undefined on 404)
• Cookie config sets httpOnly: true and secure: process.env.NODE_ENV === "production"
• secrets is read from process.env (no hardcoded strings, no committed .env.example values)
• secrets is an array supporting rotation (prepend new, keep old) — not a single value
• Every session.set/session.unset/session.flash is followed by a response with "Set-Cookie": await commitSession(session)
• Auth gate is in loader (or action) via requireUserId(request) — NOT a component-level redirect
• Logout is an action (POST), not a loader (GET)
• Mutating actions call csrf.validate(request) when CSRF protection is in use
• CSRF token uses a dedicated createCookie("csrf", ...), NOT the session cookie
• Mutations use \x3CForm> / useFetcher so AuthenticityTokenInput attaches the token (no manual fetch POST)

Valid Patterns (Do NOT Flag)

These are correct usage — do not report as issues:

• sameSite: "lax" — acceptable default. Not every app needs "strict"; flag only when threat model warrants stricter (e.g. CSRF protection is otherwise absent).
• meta returning [] — legitimate when the route intentionally emits no meta (inherits root tags or relies on a sibling).
• links returning [] — legitimate when the route has no route-specific stylesheets or preloads.
• session.flash(...) followed on the next line by commitSession(session) — the standard 2-line flash pattern. The separation is correct; do not flag it as "missing commit".
• Auth check in action (not loader) — correct for POST-only routes (e.g. logout, delete). Loaders gate GETs; actions gate mutations.
• charset and viewport as plain JSX \x3Cmeta> in root.tsx's \x3Chead> — preferred over the meta export to avoid duplicate-tag warnings under v2's no-merge behavior.
• secrets: [process.env.X!, process.env.X_OLD!] — ! non-null assertion is acceptable when a fail-fast guard above (if (!process.env.X) throw) is present.
• throw redirect(...) inside a loader/action — canonical Remix pattern; the thrown response is intentional.
• commitSession called in a loader (not just an action) — required when a loader reads a flash message and must clear it.

Context-Sensitive Rules

Only flag these issues when the specific context applies:

Hard gates (before writing findings)

Run these in order. Do not draft user-facing findings until every gate passes for the batch you are about to report.

1. Location evidence — Pass: Each issue lists a repo path and either a line range or a short verbatim quote from the file you read. Diff-only or memory-based claims do not pass. For meta/links/session issues, the cited file is a .ts/.tsx route module, root.tsx, or *.server.ts — not a generic config file.

2. Exemption check — Pass: For each issue, you can state in one line why it is not covered by Valid Patterns (Do NOT Flag). In particular: sameSite: "lax", empty meta/links arrays, and the standard flash + commitSession two-line pattern must be explicitly cleared.

3. Meta-shape check — Pass: Before flagging anything about meta, you read the actual function body and confirmed what it returns. TypeScript may have masked the shape (a v1 object can satisfy a poorly-typed MetaFunction alias). The check is: the return expression starts with [ and every element is a descriptor object. If it starts with {, that is the v1 shape — flag as CRITICAL. If it is [], that is valid (do not flag).

4. Protocol — Pass: You completed the Pre-Report Verification Checklist in review-verification-protocol for this review.

When to Load References

• Reviewing any export const meta or export const links, or root.tsx → meta-v2-shape.md
• Reviewing createCookieSessionStorage, createCookie, or any *.server.ts that configures cookies → cookie-security.md
• Reviewing loaders/actions that read or write session, or any auth helper → auth-gates.md
• Reviewing forms, fetchers, or any mutating route → csrf.md

Review Questions

1. Does every meta export return an array, and is every OG/Twitter tag { property, content }?
2. Does root.tsx include \x3CMeta /> and \x3CLinks /> inside \x3Chead>?
3. Are cookies httpOnly + secure: NODE_ENV === 'production' with secrets from env in an array (rotation-ready)?
4. Is every session mutation followed by a Set-Cookie: await commitSession(session) header?
5. Is auth gated in the loader/action via a throwing helper, never in a component?
6. Is logout an action (POST), and do mutating actions validate CSRF (or document the threat model)?

Additional Documentation

• references/meta-v2-shape.md — v1 object shape in v2 codebases (BREAKING), OG shorthand, document.title antipatterns, root scaffolding, parent merging
• references/cookie-security.md — httpOnly/secure/sameSite, hardcoded secrets, rotation hygiene
• references/auth-gates.md — loader-level gates, logout-must-be-action, commit pairing, flash patterns
• references/csrf.md — remix-utils/csrf wiring, manual-fetch bypass, dedicated cookie, shared-secret hygiene

Before Submitting Findings

Complete Hard gates (especially gate 3 — meta-shape check), then report only issues that still pass the review-verification-protocol pre-report checks.