Three backend security fixes: missing auth check on chat create, PII written to disk, hardcoded signing secret

abbyshekit's PR closes three independent backend gaps: a chat-creation endpoint that skipped project access verification, a Claude SSE stream logger that was writing PII to disk on every request, and a download-URL signer that silently accepted `dev-secret` when no real key was configured.

securityinfrastructure

The chat creation endpoint let any authenticated caller attach a new chat row to any project. The streaming chat route already checked project membership; the create variant didn't. The fix adds the same access check and validates the payload so malformed requests return 400 rather than reaching the insert. abbyshekit notes that ryanmcdonough/mike independently found the same bug.

The disk-logging issue is the most operationally dangerous of the three. The Claude provider integration was appending every SSE event from the model stream to a file in the working directory - on every chat, unconditionally. On a production deployment processing legal documents, that file was a persistent PII dump. The fix makes the mirror opt-in behind an environment flag parsed against an explicit truthy allowlist ('1', 'true', 'yes'), so values like false or 0 cannot inadvertently enable it. When active, the log file is created with restrictive permissions.

The download signing gap allowed callers to mint signed download URLs whenever DOWNLOAD_SIGNING_SECRET wasn't set, because the function fell back to the hardcoded string dev-secret. The function now throws on a missing secret. A boot-time assertion in the server entry point ensures a misconfigured deploy fails with a clear error message rather than silently degrading. Empty-string env values are trimmed to catch unfilled deployment templates.

The PR closed unmerged, thirteen minutes after opening. The author explicitly deferred a TOCTOU race, a production-mode requirement on the explicit signing secret, and bootstrapping a backend test runner.

So what The disk-logger and the hardcoded signing secret are both worth checking in your own deployment regardless of whether you pull this PR. If you're running any Mike fork in production and haven't audited those two paths, the review is the work - not the diff.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?