Impact
The Go API gateway is the public-facing bridge for live audit control routes. In live mode, a client can send a very large POST /api/v1/audit/jobs body and the gateway buffers it with io.ReadAll before forwarding. The gateway also buffers runtime responses with io.ReadAll, so a compromised or misconfigured runtime can force the gateway to allocate an unbounded response body before returning it. The HTTP listener is started through http.ListenAndServe, which leaves request header/read/write/idle timeouts and MaxHeaderBytes at net/http defaults. Together this makes the public proxy boundary easier to exhaust with slow connections, oversized headers, oversized job submissions, or oversized upstream responses.
Evidence
apps/api-go/internal/proxy/server.go line 215 reads the entire client request body in handleControlPost with io.ReadAll(request.Body) before any size check.
apps/api-go/internal/proxy/server.go lines 369 and 408 read the entire runtime response body with io.ReadAll(response.Body) before writing it back to the browser.
apps/api-go/cmd/platform-api/main.go line 134 starts the listener with http.ListenAndServe(address, handler), so the server does not set explicit ReadHeaderTimeout, ReadTimeout, WriteTimeout, IdleTimeout, or MaxHeaderBytes.
apps/web/src/app/api/v1/audit/jobs/route.ts line 38 also materializes the live-mode request body with await request.text() before proxying to the gateway, so the Node facade currently has the same oversized-submission shape.
Suggested fix
- Add small, documented maximums for audit job request bodies and runtime JSON responses.
- Enforce request limits before buffering, ideally with
http.MaxBytesReader in the Go gateway and an early content-length/body-size guard in the Next facade.
- Read runtime responses through a bounded reader and return a generic
502/413 style response when limits are exceeded.
- Replace
http.ListenAndServe with an http.Server configured with explicit read/header/write/idle timeouts and MaxHeaderBytes.
- Add regression tests for oversized job submissions, oversized runtime responses, and listener config.
Notify: Developer Agent
Impact
The Go API gateway is the public-facing bridge for live audit control routes. In live mode, a client can send a very large
POST /api/v1/audit/jobsbody and the gateway buffers it withio.ReadAllbefore forwarding. The gateway also buffers runtime responses withio.ReadAll, so a compromised or misconfigured runtime can force the gateway to allocate an unbounded response body before returning it. The HTTP listener is started throughhttp.ListenAndServe, which leaves request header/read/write/idle timeouts andMaxHeaderBytesat net/http defaults. Together this makes the public proxy boundary easier to exhaust with slow connections, oversized headers, oversized job submissions, or oversized upstream responses.Evidence
apps/api-go/internal/proxy/server.goline 215 reads the entire client request body inhandleControlPostwithio.ReadAll(request.Body)before any size check.apps/api-go/internal/proxy/server.golines 369 and 408 read the entire runtime response body withio.ReadAll(response.Body)before writing it back to the browser.apps/api-go/cmd/platform-api/main.goline 134 starts the listener withhttp.ListenAndServe(address, handler), so the server does not set explicitReadHeaderTimeout,ReadTimeout,WriteTimeout,IdleTimeout, orMaxHeaderBytes.apps/web/src/app/api/v1/audit/jobs/route.tsline 38 also materializes the live-mode request body withawait request.text()before proxying to the gateway, so the Node facade currently has the same oversized-submission shape.Suggested fix
http.MaxBytesReaderin the Go gateway and an early content-length/body-size guard in the Next facade.502/413style response when limits are exceeded.http.ListenAndServewith anhttp.Serverconfigured with explicit read/header/write/idle timeouts andMaxHeaderBytes.Notify: Developer Agent