Skip to content

fix: sanitize error responses to prevent internal detail leakage#2456

Open
pablo-ibco wants to merge 1 commit into
developfrom
pborges/fix-sanitize-500-error-responses
Open

fix: sanitize error responses to prevent internal detail leakage#2456
pablo-ibco wants to merge 1 commit into
developfrom
pborges/fix-sanitize-500-error-responses

Conversation

@pablo-ibco
Copy link
Copy Markdown
Contributor

Summary

  • Sanitize the fallback 500 error response in apiHandler to stop
    leaking internal error details to API clients
  • Remove leaked headers from OpenAI API error responses

Motivation

The errorHandler in app/src/util/api.ts has a fallback branch for unrecognized errors that was extracting err.message and returning it in the JSON body alongside "Internal server error". This could expose:

  • Database/driver error messages (e.g. connection strings, table names)
  • Stack trace fragments
  • Internal service details

The OpenAI error branch was also forwarding headers from the upstream OpenAI API response, which could contain rate limit details or other internal metadata that clients should not see.

Changes

  • Fallback 500: return only { error: { message: "Internal server error" } }
    without the raw error string (the full error is still logged server-side
    via logger.error(err) on line 422)
  • OpenAI errors: return { error: { name, message } } without headers

Test plan

  • Trigger a 500 error and verify the response body contains only
    the generic message, not internal details
  • Verify server logs still contain the full error for debugging
  • Run existing API tests (npm run ci:test)

The fallback 500 error handler was sending raw error messages to
clients, potentially exposing database errors, driver messages, or
other internal details. The OpenAI error handler was also forwarding
response headers from the upstream API.

Errors are still fully logged server-side via the existing
logger.error() call.
Comment thread app/src/util/api.ts
errorMessage = (err as Object).toString();
}
return NextResponse.json(
{ error: { message: "Internal server error", error: errorMessage } },
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get the idea here of not accidentally leaking database details (hoewever all of our DB structure etc. is available publicly in this repository), for now I would hold off on merging this though.
This information can be crucial for debugging and until we have Grafana fully set up on our prod environment we kind of rely on this to debug it.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lemilonkh nice! Do we have on our roadmap when we plan to have Grafana fully set up or is it something being discussed yet?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants