security: stop trusting the leftmost x-forwarded-for for rate limits and abuse quotas (FRE-371)

getClientIP (the rate-limit and audit key) took the LEFTMOST x-forwarded-for
hop and read x-real-ip unconditionally. In our topology — client → Cloudflare
→ same-host origin proxy → app — both proxies APPEND, so the leftmost hop is
whatever the sender typed: a rotating X-Forwarded-For minted a fresh rate-limit
bucket per request, and unlimited bug-report quota via the same pattern in
routes/api/the-nook/report.ts. x-real-ip is client-settable too; nothing in
the chain overwrites it. It is no longer read at all.

New trust order (src/server/trusted-client-ip.ts, resolveTrustedClientIp):

  1. a non-loopback socket peer IS the client — its headers are ignored;
  2. cf-connecting-ip (Cloudflare overwrites it at the edge; parsed as an
     address or rejected);
  3. x-forwarded-for counted from the RIGHT, discounting one hop for the
     Cloudflare edge address the origin proxy appended (the topology has
     exactly one trusted proxy below Cloudflare);
  4. "unknown" — callers key stricter shared limits on it, so resolution
     fails closed toward a tighter bucket, never a looser one.

Addresses are never truncated: a /24-truncated key would pool attackers with
the innocents behind them.

Share-vs-copy, stated deliberately: this is a port of the parsing primitives
 FRE-366 reviewed in request-client.ts, NOT an import. resolveClientIp carries
a standing rule (1d9287a) that it never feeds a security decision; lifting
that rule for these callers would couple an access-control change to an
analytics branch under review, and the analytics helper only exposes
truncated prefixes while rate limiting needs the full address. If the two
drift, trusted-client-ip.ts is the one security paths follow. The deploy-side
precondition (origin reachable only via Cloudflare + the same-host proxy) is
documented in the file header; if the app is ever directly internet-reachable
no in-app read can recover the true client.

Tests updated deliberately, not to go green: rate-limit.test.ts now pins the
rightmost-minus-one order, cf-connecting-ip precedence, peer-over-headers,
x-real-ip rejection, and the spoof case (a rotating leftmost hop does not
change the resolved client); report.test.ts pins the quota key stability
under a rotating header. New trusted-client-ip.test.ts covers the helper's
own edges: APIEvent wrapper, loopback forms, unparseable hops failing closed.

src/routes/api/the-nook/report.test.ts

@@ -10,6 +10,8 @@ import { describe, expect, it, mock, beforeEach } from "bun:test";
 
 const sentEmails: { to: string; subject: string; html: string }[] = [];
 const tokenAnswers: { allowed: boolean; retryAfterSec?: number }[] = [];
+/** Every rate-limit key the route derived, in order. */
+const rateKeys: string[] = [];
 
 mock.module("~/server/email", () => ({
   default: async (to: string, subject: string, html: string) => {
@@ -19,7 +21,10 @@ mock.module("~/server/email", () => ({
 }));
 
 mock.module("~/server/bug-report-rate-limit", () => ({
-  takeBugReportToken: () => tokenAnswers.shift() ?? { allowed: true }
+  takeBugReportToken: (key: string) => {
+    rateKeys.push(key);
+    return tokenAnswers.shift() ?? { allowed: true };
+  }
 }));
 
 const { POST } = await import("./report");
@@ -72,6 +77,7 @@ describe("POST /api/the-nook/report", () => {
   beforeEach(() => {
     sentEmails.length = 0;
     tokenAnswers.length = 0;
+    rateKeys.length = 0;
   });
 
   it("emails the owner a report containing the snapshot, escaped", async () => {
@@ -133,10 +139,49 @@ describe("POST /api/the-nook/report", () => {
 
   it("still succeeds when no fingerprint header exists", async () => {
     const res = await POST(
-      request(validPayload, { "x-forwarded-for": "203.0.113.9, 10.0.0.1" })
+      request(validPayload, {
+        "cf-connecting-ip": "203.0.113.9",
+        "x-forwarded-for": "203.0.113.9, 10.0.0.1"
+      })
     );
     expect(res.status).toBe(200);
     expect(sentEmails).toHaveLength(1);
+    // The quota key is the Cloudflare-recorded client, not a header hop the
+    // sender chose.
+    expect(rateKeys).toEqual(["203.0.113.9"]);
+  });
+
+  it("a rotating leftmost x-forwarded-for does not mint a fresh quota key", async () => {
+    // FRE-371: the old read keyed on the leftmost hop, which the sender
+    // controls outright — one scripted loop with a rotating header had
+    // unlimited reports. With the same Cloudflare-recorded client and a
+    // different spoofed prefix per request, the key must be stable.
+    for (const spoof of ["1.1.1.1", "2.2.2.2", "3.3.3.3"]) {
+      const res = await POST(
+        request(validPayload, {
+          "cf-connecting-ip": "203.0.113.9",
+          "x-forwarded-for": `${spoof}, 203.0.113.9, 10.0.0.1`
+        })
+      );
+      expect(res.status).toBe(200);
+    }
+
+    expect(rateKeys).toEqual([
+      "203.0.113.9",
+      "203.0.113.9",
+      "203.0.113.9"
+    ]);
+  });
+
+  it("keys on the rightmost-minus-one hop when Cloudflare's header is absent", async () => {
+    const res = await POST(
+      request(validPayload, {
+        "x-forwarded-for": "6.6.6.6, 203.0.113.9, 10.0.0.1"
+      })
+    );
+    expect(res.status).toBe(200);
+    // Never the leftmost (sender-chosen) hop.
+    expect(rateKeys).toEqual(["203.0.113.9"]);
   });
 
   it("delivers the landing page's beta request with only the email", async () => {