Enable custom errors to restrict users from seeing sensitive information such as the paths, stack trace and .NET version information. A potential hacker can get a lot of information on your environment just by looking at the default error page.
There are several things you could do to secure your Sitecore instance, namely the Sitecore Security Hardening Guide. Along with the documented steps, there are several others you should implement to secure your instances.
The good thing is that Sitecore by default sets the customErrors to RemoteOnly. This way it shows you the information when you are working locally and will display generic information when accessing the site remotely.
Most of us are used to setting up a default 500 and 404 pages but I have seen in some instances that developers forget. The best thing to do is to set the default 500 page. For now I am going to set it to a physical Html file. There are different schools of thought depending on the security team you need to answer to. The ones I have had to deal with argue that if you set it to a Sitecore page /500 for instance, it might cause a recurring loop if Sitecore solution code itself is an issue. Instead if you use a standalone 500.html file, it will render always. The disadvantage is that we are unable to manage content on this file without code change.
This is better but we can do better. By default the redirectMode is ResponseRedirect and it places the path in the url. To overcome that we add in the redirectMode as ResponseRewrite so that the url where the error occurred stays as is but the response will be shown from the custom error page.
If you have any questions or concerns, please get in touch with me. (@akshaysura13 on twitter or on Slack).