Can you give too much information in your error messages?

Boston CartwrightBoston Cartwright | March 30, 2021 | golang
3 min read | ––– views

Times when errors are better to be unspecific

Want to check this out later?

I joined a new team this last week and have the chance to learn from some very cool senior engineers.

We are working on some micro services in Golang, and as part of one of these services we wanted to build some basic authorization using OAuth 2.0.

In our service, we do a number of steps in order to authorize a user:

  authorized, err := authorize(request)
  if err != nil {
    return nil, fmt.Errorf("there was an error")
  }

I had to make a small edit somewhere else in this package, and saw this error. I immediatly noticed that it was not descriptive at all, and that if someone ran into this error they wouldn't know how to fix it.

As part of my work, I included a change to this string:

  authorized, err := authorize(request)
  if err != nil {
    return nil, fmt.Errorf("user token has incorrect field: SOME_FIELD")
  }

I was happy with my change and figured that if someone was attempting to authenticate with our service and ran into an issue, this could help them to solve it.


When I opened a pull request including this change, there were quickly some comments about it with the main point being that we don't want to give too many hints as to why a request was not authorized.

I was perplexed by this at first, but was able to discuss with my team to understand the reasoning behind this.

If you have taken any security training, you know that there are malicious actors everywhere.

While our authorization should prevent as many threats as possible, if we are able to provide some added security through obscurity, we can prevent even more from getting unauthorized access.

This works since only we should know the inner workings of our authorization flow and those needing to authorize with it should know just as much as needed.

A very simple example of this is one commonly seen when logging into any system. If you get your username or password incorrect, a smart system won't tell you which one.

password taken by another user

Image by @rSoftwareGore on Twitter

I thought this was a really cool lesson to have learned and I am grateful to have some cool senior engineers I can ask about these things!

What do you think? Let me know @bstncartwright