Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Error Handling with malformed json #365

Open
comrt opened this issue Mar 29, 2024 · 2 comments
Open

Improve Error Handling with malformed json #365

comrt opened this issue Mar 29, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@comrt
Copy link

comrt commented Mar 29, 2024

Currently Jackson and Jsonb Exception Mappers return responses, which contain detailed information about the malformed request object. From a consumer point of view this makes sense and improves developer expierence.

Example:
{ "status": 400, "title": "Bad Request", "detail": "Internal error: Invalid token=STRING at (line no=3, column no=11, offset=52). Expected tokens are: [COMMA]", "instance": "/token" }

But the responses also contain implementation details, which from a security point of view is not so good. Especially if your service is a an external public API.
https://owasp.org/www-community/Improper_Error_Handling
Example:
{ "status": 400, "title": "Bad Request", "detail": "Unable to deserialize property 'token' because of: Problem adapting object of type interface org.example.entity.Token to class java.lang.String in class class org.example.enity.TokenTypeAdapter", "instance": "/token" }

Solution

What could help is an option to control the output to return a more generic response and log the detailed error message in the backend.
Example:
{ "status": 400, "title": "Bad Request", "detail": "Syntax Error: malformed json", "instance": "/token" }

@lwitkowski
Copy link
Collaborator

@comrt, that's a very good point. I thought about it a bit in the past, and dropped the idea after thinking about configurability, possible localisation issues etc. But I definitely see a value in your proposal, so will give it another shot.

Few options I see at the moment:

  • opt in/out for the details field in the response
  • hardcoded, simplified error message for certain exceptions (like json parsing)
  • same as above, but configurable via properties
  • ResourceBundles support for multilingual apis

@lwitkowski lwitkowski added the enhancement New feature or request label Mar 29, 2024
@comrt
Copy link
Author

comrt commented Mar 29, 2024

@lwitkowski as the default exception mapper returns also no details
{ "status": 500, "title": "Internal Server Error", "instance": "/apis" }
the opt in/out solution sounds viable to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants