Pracht Audit Redirects

The classic open-redirect bug: /login?redirect=https://evil.example → after login, the app redirects the user to attacker territory carrying a fresh session.

What the framework guarantees: the client router drops non-http(s): schemes at the navigation boundary, and server-side redirect() / buildRedirectResponse() reject non-http(s): schemes and CR/LF injection against the Location header. What it cannot decide is whether the target origin or path is one you trust — and a raw new Response(null, { status: 302, headers: { location: userInput } }) bypasses all of those guards entirely.

Prerequisites: pracht inspect requires a vite config that registers the pracht plugin.

Step 1: Inventory redirect sites

Bound the search first — do not grep the whole repo blind:

pracht inspect routes --json

MCP: if pracht dev-mcp is registered, prefer its inspect_*, doctor, and verify tools to the CLI.

The resolved graph gives you each route's file, loaderFile, and middleware names (resolve names to files via the defineApp({ middleware }) map in the manifest). Grep those files plus the API handler files from pracht inspect api --json, and client components, for two distinct classes:

Class A — guarded sites (scheme/CRLF-safe, still open-redirect capable):

• Middleware/loaders/handlers returning redirect(...) or buildRedirectResponse(...).
• useNavigate()(value) and <a href={value}> where value is dynamic (client guard applies).
• prefetchRouteState(value) calls with dynamic input.

Class B — unguarded sites (bypass every framework guard):

• Hand-rolled 3xx Responses: new Response(null, { status: 302, headers: { location: ... } }) or headers.set("location", ...) in loaders, middleware, or API handlers. With user input these allow not just open redirects but also unsafe schemes and header-injection attempts — flag at higher severity.

Step 2: Trace the input

For each site, identify whether the redirect target is:

• Static — string literal. Safe.
• Internal-derived — built from params, route.path, or a closed allowlist. Safe if the allowlist is verifiable.
• Request-derived — read from url.searchParams.get(...), request.headers.get('referer'), request body fields, cookie values, or query parameters. Suspect.

Common suspect names: redirect, redirectTo, next, returnTo, continue, url, dest, goto.

Step 3: Check the gate

For each request-derived target, look for one of:

Prefix checks are not sufficient. //evil.example/path is protocol-relative, and URL parsing turns \ into / and strips tabs and newlines, so /\evil.example and /\t/evil.example pass startsWith('/') && !startsWith('//') yet land on another origin. Only an origin comparison after new URL(target, url) is a real gate.

Remember: redirect()'s built-in validation covers scheme and CRLF only — it happily redirects to any well-formed http(s) origin, so Class A sites still need an origin/path gate for request-derived targets.

Step 4: Report

Severity is the primary scale; the verdict is a secondary domain label:

• error / open — request-derived target, no check. A Class B site here is the worst case (no scheme/CRLF guard either) — say so explicitly.
• warn / risky — substring/regex check; suggest URL-parse rewrite.
• info / safe — static or properly gated. For Class B sites that are static today, still recommend migrating to redirect() so the scheme/CRLF guards apply if the target ever becomes dynamic.

For each open/risky finding, propose a fix snippet, e.g.:

function safeRedirectPath(value: unknown, base: URL, fallback: string): string {
  if (typeof value !== "string" || !value.startsWith("/")) return fallback;
  try {
    const target = new URL(value, base);
    return target.origin === base.origin
      ? `${target.pathname}${target.search}${target.hash}`
      : fallback;
  } catch {
    return fallback;
  }
}

return redirect(safeRedirectPath(url.searchParams.get("redirect"), url, "/dashboard"), {
  request,
});

Step 5: Cross-check with the framework guards

Note in the report that pracht drops javascript:, data:, vbscript:, blob:, and file: schemes both in the client router (since #122) and in server-side redirect()/buildRedirectResponse() — so a guarded open redirect cannot become script execution. But it can still phish (redirect to a look-alike origin) and leak session/referrer headers, and Class B raw Responses get none of this protection.

Rules

1. Default to suspicion for any request-derived target.
2. Recommend URL parsing over string prefix checks for non-trivial gates.
3. Do not trust referer as a gate; it is forgeable and often stripped.
4. After-login redirects are the most dangerous — user is authenticated.
5. Recommend redirect() over hand-rolled 3xx Responses so the scheme/CRLF guards apply.
6. Do not auto-fix; surface the gap and propose the patch.

$ARGUMENTS