Harden application security boundaries and abuse resistance

[DenWin]

Parent: #31. Coordinate with #11, #15, #17, #19, and #20.

Current evidence

• maxRequestBodySize is Number.MAX_SAFE_INTEGER.
• Upload count, aggregate size, and per-file size are not bounded by the server.
• Authentication has no documented brute-force/rate limiting.
• File conversion launches many powerful native tools against untrusted input.
• Path safety relies on repeated sanitation/path construction across routes.
• Security headers, CSP, origin/CSRF strategy, and request-rate policy are not centrally defined.
• JWT persistence and rotation require a secure design (Support explicit local, OIDC, and built-in authentication modes #11).

Required threat model

Document assets, trust boundaries, attacker capabilities, abuse cases, and accepted residual risks for:

• authentication and account changes
• upload and decompression/parser bombs
• file/path handling and output naming
• native converter subprocesses
• result/download authorization
• anonymous modes
• browser injection and request forgery
• denial of service through CPU, memory, disk, process count, and long-running jobs

Required controls

• Bounded request body, file count, per-file size, aggregate size, and storage quotas.
• Rate limits/backoff for login and expensive operations.
• Central path-containment checks using resolved paths, not sanitation alone.
• MIME/content validation policy distinct from extension selection.
• Converter allowlists and validated typed options.
• Subprocess timeouts, output limits, environment minimization, and cancellation.
• Secure response headers and a reviewed CSP.
• Explicit CSRF/origin policy for state-changing requests.
• Safe error responses without secrets, paths, or command details.
• Audit-relevant security logging without credential/token leakage.
• Safe archive creation/extraction policies.
• Documented handling for malicious or unsupported files.

Verification

Use negative tests from #19/#20, real malicious edge fixtures where safe, and container-level resource tests. Controls must fail closed.

Acceptance criteria

• Threat model is reviewed and linked from architecture docs.
• Unbounded request/upload behavior is removed.
• Ownership and path containment are centralized and sensitivity-tested.
• Authentication and expensive routes resist basic abuse.
• Native processes have enforced resource/time/output limits.
• Browser security headers and state-change protection are tested.
• Security failures are observable without exposing sensitive data.