Audit of the shipped Chistyy PDF feature against the actual code found
three documentation defects and one misplaced gate:
- The SSRF write-up understated the hole. assertPublicUrl resolves DNS
exactly once, for the initial URL; the in-browser filter never resolves
hostnames at all. Any new hostname after the first navigation (redirect,
subresource, fetch, ws://) goes unchecked - a DNS rebind is not even
required. Corrected in TECHNICAL.md and the design spec.
- The prod gate was tied to TOOLBOX_VISIBLE, but /api/pdf sits in
PUBLIC_ROUTES and authenticates itself, so the feature goes live the
moment browserless and BROWSER_WS_URL appear on prod - before the flag.
Gate is now tied to the renderer.
- TECHNICAL.md claimed the browserless port is published on neither
staging nor prod. It is published on dev/staging (127.0.0.1:3333) and
the SSH tunnel depends on it.
- AGENTS.md described a src/proxy.ts that does not exist; route protection
lives in src/middleware.ts.
Also adds a state snapshot (docs/plans) and a "grabli uklada" section to
CLAUDE.md covering the non-obvious conventions already enforced in code:
the two ToolUsage ids, the vitest include pattern, page.pdf() without a
timeout option, context.route not seeing WebSockets, and NEXT_PUBLIC_*
being inlined at build time.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Sy7vY7WQ1A3q1MkgsDd8VB
The security docs claimed the in-browser SSRF filter (context.route/
routeWebSocket) re-applies "the same filtering" as the pre-fetch DNS
check. That's inaccurate for hostnames: the browser-level filter only
blocks literal private IPs and localhost/.local/.internal suffixes —
it never re-resolves hostnames, so a same-hostname DNS-rebind (public
IP on first resolve, private IP on a later request from inside
browserless) is not closed at that layer. Correct the wording in the
design spec and TECHNICAL.md, and add a prominent note to both the
spec's deploy section and the plan's deploy notes: before flipping
TOOLBOX_VISIBLE on prod, harden the browserless container's network
egress (block 169.254.0.0/16 and RFC1918 ranges via host firewall or
a dedicated internal docker network) to close the residual at the
network layer. Also note that per-user limits currently count only
successful generations — failed renders are uncapped, a bounded
self-DoS risk worth a follow-up.
adminsandClaude Opus 5