{"id":59736,"date":"2022-11-06T15:21:21","date_gmt":"2022-11-06T07:21:21","guid":{"rendered":"https:\/\/version-2.com\/?p=59736"},"modified":"2023-07-24T18:41:14","modified_gmt":"2023-07-24T10:41:14","slug":"error-handling","status":"publish","type":"post","link":"https:\/\/version-2.com\/zh\/2022\/11\/error-handling\/","title":{"rendered":"Error Handling"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

<\/span><\/p>

I decided to focus this article on Error handling because it is a very common security problem if it is not handled properly. This topic is very tightly coupled with logging, but for this article, I will just cover error handling.<\/span><\/p>

I saw on many websites that error messages presented to the user (in this case, me) need to be handled properly so they don’t reveal implementation details. You are familiar with the fact that hackers will look deeply into these messages because they know that if they contain information that should not be revealed, they could help them and be like little clues made out of exploitable pieces.\u00a0<\/span><\/p>

The most common errors I have seen were detailed internal error messages which are displayed for the user, even sometimes as toast messages.<\/span><\/p>

\u00a0<\/h4>

Why are internal errors presented to the users?\u00a0<\/em><\/span><\/h4>

The first problem is always the lack of documentation for the web application. By that, I mean that often due to the time deadlines when setting up the architecture creating the documentation ends up being somewhat neglected.\u00a0<\/span><\/p>

Also, logging is often implemented as the last step when setting up the architecture or even after some basic functional code is written. And then, with the lack of documentation about error handling, developers often try to follow the steps of the error handling code they find in the application without any consistent guidance. And in the end, you get messy code, poorly implemented error handling, and exposed data that should not be revealed!<\/span><\/p>

Where should errors be handled in the web application?<\/em><\/span><\/h4>

\u00a0<\/h4>

First, in the mentioned documentation for the web application. There should be defined a policy that will define which types of errors should be handled, what messages should be presented to the user, and what information should be logged.<\/span><\/p>

You can choose where you should handle the errors. It would be eighter on the server side, on the client side, or even both.\u00a0<\/span><\/p>

*In my practice, I handled the server errors in the API and sent the proper user message to the client side to be presented to the user if needed. I created a custom error handler for the client errors and presented user-friendly error messages again.<\/span><\/p>

Tips for the error messages style on the client side<\/em><\/span><\/h4>

In this list, I will focus just on the error messages style, which will be presented for the user eighter they are created on the client side or the server side and sent to the client side.<\/span><\/p>