[Game Streamer] Spec-server input hardening (body size, job_id path, output_fps clamp)

[Flegma]

Summary

Defense-in-depth input hardening for the game-streamer spec-server (:1350). Three unrelated-but-adjacent gaps on the same server: request bodies are buffered with no size or time limit, job_id is used verbatim in filesystem paths, and output_fps is accepted with no range clamp. This is a companion to the spec-server authentication issue (#531); even once the endpoint is authenticated, these values should be validated.

Location

game-streamer:

• src/spectator/util/http.mjs:17-29 : readJsonBody accumulates every chunk into an in-memory array and only concatenates on end, with no byte cap and no idle/overall timeout (Node imposes no default body-size limit). Every POST route goes through it. (JSON.parse itself is correctly wrapped in try/catch.)
• src/spectator/routes/render-clip.mjs:10 : jobId = String(body.job_id ?? "") with no format check, then passed as CLIP_RENDER_JOB_ID env into lib/inline-clip-render.sh, which interpolates it into output paths (e.g. ${CLIP_OUT_DIR}/${CLIP_RENDER_JOB_ID}.mp4). A traversal value escapes the clips directory on write/rm.
• src/spectator/routes/render-clip.mjs:14 : outputFps = Number.parseInt(body.output_fps, 10) || 60 accepts negatives and absurdly large values (only 0/NaN fall back to 60); forwarded as CLIP_OUTPUT_FPS into Remotion (durationInFrames = duration * fps) and ffmpeg.

Impact

• Body size: a multi-gigabyte or slow-loris body to any POST route buffers in RAM until the pod OOM-kills; because the pod is host-networked, that takes streaming down for the whole node. Triggerable even by a well-behaved-but-buggy caller.
• job_id traversal: a value like ../../../opt/game-streamer/resources/video/outro_1920x1080_60 makes rm -f/ffmpeg target files outside the intended directory. Job ids are normally server-generated UUIDs, so this needs a buggy/compromised api, hence P3, but the route offers no defense.
• output_fps: a huge value makes Remotion compute an astronomical frame count and pin a render slot/GPU indefinitely; a negative value makes ffmpeg abort the job.

Suggested Fix

• readJsonBody: reject with 413 once accumulated length exceeds a small cap (for example 1 MB) and enforce a request timeout, destroying the socket when exceeded.
• job_id: reject anything not matching /^[A-Za-z0-9_-]{1,64}$/ before spawning the render.
• output_fps: clamp to a sane range, e.g. Math.min(120, Math.max(1, parsed)) defaulting to 60.

---

Found by the 2026-07 multi-agent audit; verified against current code. Companion to #531 (spec-server authentication).

[Flegma]

The 2026-07 audit found an additional spec-server input-robustness gap in the same dispatch path, fold into this issue:

Location: src/spectator/routes/index.mjs:102

What: dispatch() parses the body with readJsonBody and passes it straight to handlers, but readJsonBody resolves whatever JSON.parse returns, including null for a literal 'null' body (only empty raw is coerced to {}). Most handlers (seekHandler, skipHandler, speedHandler, roundHandler, execHandler, xrayHandler, the /spec/* handlers) immediately dereference body. without a null guard, unlike switchMatchHandler which checks typeof body.

Impact: A client POSTs the raw body null to e.g. /demo/seek; JSON.parse yields null, seekHandler does Number.parseInt(null.tick) which throws, dispatch's catch returns 500 'internal' and writes a full stack trace to stderr. Trivial malformed input yields a 500 instead of a 400 and floods logs with stack traces.

Suggested fix: In readJsonBody (or dispatch) coerce a non-object parse result to {} (e.g. return parsed && typeof parsed === 'object' ? parsed : {}), so handlers get a safe object and malformed bodies return 400.

[Flegma]

Deferred from the 2026-07 fix pass. Companion to #531; the input validation (body cap, job_id format, output_fps clamp) is safe on its own but was grouped with the spec-server auth work. Worth its own small PR. See the fixes summary doc (docs/plans/2026-07-10-audit-fixes-summary.md) for the full deferral rationale.