Secure error messages from public API

Question

We are writing our first public API.

Now I remember hearing in the past that you shouldn't give users useful error messages, that allows hackers to learn what your data is.

so if the get is

{
 policyNumber: '43',
 product: 'car insurance'
}

the error message shouldn't give the user enough information to refine their search and carry on hunting for real data.

so not

'sorry this type of insurance doesn't have a policy numbered that'

But my memory is really vague, and my google search skills aren't up-to finding this sort of information out. Or I misunderstood and I am wrong, and this only applies to user name and password.

Please help.

Are there any guidelines in how error messages should be worded for security purposes, what should and what shouldn't be provided to the end user.

Answer 1

Great question! I don't know that there are any hard-and-fast rules here, but you're definitely on the right track.

Here are some things that I look for when I'm looking at the descriptiveness of log and error messages, I generally think along these lines:

• Error messages in internal log files are descriptive enough to help with debugging and live attack monitoring.
  • If there's PII (customer names, IP addresses, etc) in the internal logs, that's probably OK, but check compliance laws and make sure these logs are being properly protected.
• Customer-facing error messages:
  • Visible pre-authentication should be static strings that are very generic. Ie do not echo back any dynamic content.
  • Visible only to a logged-in user: can be a little more flexible, for example it's not a vulnerability to tell a user their own name or their own account number, but as you point out, you want to keep this to a minimum because you're only one bug away from leaking info about other users, or leaking info about internal server state.
• Under no circumstances should a customer-facing error message contain a stack trace.

---

Generally speaking, you're in a usability-vs-security tradeoff here. More descriptive error messages will help users figure out what they did wrong, and generally have an easier time using your product. That said, the more descriptive they are, the more you're asking for security issues.