[Deicyde]

Problem

• The CSP report sink has no rate limit. POST /api/csp-report (wiki: security headers on Worker responses + report-only CSP #47) is unauthenticated by necessity, since browsers send the reports. It caps the body size and the violations per log line, but not the request rate, so anyone can flood the Worker's logs. Every other unauthenticated write has a limiter: /api/flag uses FLAG_LIMITER.
• The header comment in wiki/src/security.ts gives a misleading next step. It says to "tighten it, then enforce it, once /api/csp-report stays quiet". The report-only policy allows 'unsafe-inline' scripts, so enforcing it as written would add little XSS protection.

Change

• The sink checks FLAG_LIMITER before reading the body (ahead of Security hardening: agent sandbox, fail-closed auth, request caps, static headers, token sealing #84's readBodyCapped). It uses its own csp:<ip> keys, so it gets 5 requests a minute per IP without touching the flag route's budget. A Reporting API request can batch several reports. Past the limit it answers 429 and logs nothing.
• The header comment says the policy allows inline scripts, and that the reports show what a stricter policy would break, with the inline scripts moved out first.
• No new binding. FLAG_LIMITER's comments in wiki/src/env.ts and wiki/wrangler.jsonc now say it also caps the sink: the counters are separate but the limit and period are shared, so retuning the flag limit retunes the sink too.
• Rebased on Security hardening: agent sandbox, fail-closed auth, request caps, static headers, token sealing #84 by merging main; Security hardening: agent sandbox, fail-closed auth, request caps, static headers, token sealing #84 rewrote security.ts, and the change is re-applied on top of its sink.

How tested

• New test in wiki/test/security-headers.test.ts. It captures the limiter key from a request with CF-Connecting-IP: 203.0.113.7 and asserts csp:203.0.113.7. It sends malformed JSON while the limiter refuses, and expects 429 (not the 400 malformed JSON gets), the security headers, and no log line. It fails if the key prefix changes or the check moves after parsing. The existing sink tests use the fixture's always-allow limiter and are unchanged.
• test/security-headers.test.ts passes locally (13 tests); CI on this PR runs the full Worker suite.

Risks

• A page with many violations from one IP loses the reports past 5 a minute. The sink exists to show that violations happen, not to count each one.

Release

• Release-affecting (per site/ops/brain_release_authority.py): wiki/src/security.ts, wiki/src/env.ts and wiki/wrangler.jsonc. It ships only through a Brain release and promotion. Release B is being built at the current main (Attest the non-Brain public assets for Brain release B #82), so merge this after B is promoted; it rides the next release.

What Jack must do

• Nothing beyond the release.

[Deicyde]

Recommendation: merge, timed against release B (at 6b09390c, CI green; the review's fixes are in, rebased onto #84):

• The limiter runs on Security hardening: agent sandbox, fail-closed auth, request caps, static headers, token sealing #84's sink before the body is read.
• FLAG_LIMITER's comments in env.ts and wrangler.jsonc now say it also caps the sink.
• The test captures the csp:<ip> key and sends malformed JSON while the limiter refuses. It fails if the prefix changes or the check moves after parsing.
• The comment says 5 requests a minute.

Release-affecting. Release B now has to be built at eaa5950b or later, because #83 and #84 are release-affecting too. Merging this before that build includes it in B; otherwise merge it after B is promoted. Never merge it between the build and the promotion.

Posted by the WikiLean PR swarm (lead); updated 2026-10-18.