401 vs 403 Error Codes: What's the Difference?

Published by Fernando Doglio on August 06, 2024
401 vs 403 Error Codes: What's the Difference?

If you've been working as a web developer for a while, chances are, you've faced either one of these two error codes, or both. Error codes 401 and 403 are related to each other, and because of that, sometimes they tend to be mixed up together. However, they don't reference the same type of error, and consequently, they're not solved through the same means. In this article, we're going to review what each of these error codes mean and what you can do to solve them.

Understanding HTTP Error Codes

First things first, we need to cover what HTTP error codes are and how to interpret them. Thankfully, the HTTP standard provides some rules to help us understand what we're seeing.

HTTP response codes are separated into five different categories:

  • 1XX: Notification messages, nothing's wrong here, this is just information.
  • 2XX: Success messages, these codes mean the operation you requested took place.
  • 3XX: Redirects. These are used to signal that the resource you're requesting has been moved somewhere else.
  • 4XX: Errors in the request. These error codes are telling you that you're the one making a mistake in the request.
  • 5XX: Server errors. When you see one of these error codes, something went horribly wrong in the server.

With this in mind, we can figure out that both error codes 401 and 403 are related to us, as users, and our request data. This means we have the power to fix both errors—or at least to understand how to stop them from happening.

Understanding HTTP Error Code 401

Officially, the HTTP error code 401 means "Unauthorized"; however, in practice, this error code generally means "Unauthenticated". In other words, the client (or user) needs to authenticate before even trying to access the resource.

Some example scenarios where a 401 would arise include:

  • Trying to read an email before logging in to the account
  • A microservice trying to send a request to another microservice without properly identifying itself (like sending a JWT token, or an API key, etc).

In both situations, the problem lies within the actual request—hence the 4XX type of error. It's not a problem with the server as the actual request hasn't been authenticated before trying to access the requested resource (whatever it might be).

How Can You Fix a 401 Error?

The first thing to understand is if the error is due to a problem on the system's side (something you as a developer can fix) or on the user side, which is the first place we tend to look. So, when you see the 401 error on your logs, the first thing is to understand the source of the problem.

If the problem is due to a client or user that hasn't been properly authenticated, the solution is simple: you don't do anything, as this is not a mistake. Indeed, this is your platform properly enforcing the security standards you programmed and configured. Good job!

If that's not it, however, then you're looking for potential sources for this response code.

  • Is it expired sessions? Maybe the client has been authenticated in the past, but the session has expired since then. If that's the case, you can look at the session's timeout values—maybe they're too short and you're forcibly logging out your users.
  • Has the API key been revoked? Similarly to the expired sessions, if an API key is revoked, the systems using it will suddenly start receiving a 401 error code. Be careful when revoking API keys; keep track of who's using them and how actively they're being used in requests.
  • Is the problem due to a resource with its location public, even though the resource itself is private (i.e. it requires the client to be authenticated)? If that's the case, then the most likely solution is to hide the location of the resource until the client has properly authenticated.

Understanding HTTP Error Code 403

The meaning of the 403 error code is "Forbidden". In this case, the identity of the client is known to the server (so the authentication step happened), however the client doesn't have permission to access the requested resource. Unlike with the 401 error—where you might have permissions but just haven't properly authenticated yourself—with 403 you have authenticated yourself, but you're simply not allowed to access it.

The difference is subtle but significant. In fact, we have a blog post just about the differences between authentication and authorization which you should definitely check out.

Fixing The HTTP 403 Error Code

As with the 401 code, the first step to fixing your 403 error code, is to understand the source of the error. Be careful! It could very well be a valid response from your system for requests trying to access resources that simply can't be accessed.

If you're looking for potential sources of the 403 response code, consider the following:

  • Is the source of the 403 response code a request from a user/system that you know doesn't have access to the resource? If that's the case, then don't worry: your system is behaving as expected.
  • Is it actual lack of permissions? Maybe the user or system doesn't have enough permissions to access the requested resource. Double-check your configuration and the authorization system you're using. In fact, consider using an Authorization as a Service system, which would greatly simplify this entire process.
  • Is the IP Blacklisted? Maybe the user/system does have enough permissions, but for some reason you're blacklisting IPs. Instead of splitting your authorization logic, consider implementing something like ABAC (Attribute-based Access Control) and incorporate the IP or any other property of the user into the authorization process.
  • Is it an invalid action? Keep in mind that "accessing a resource" can be defined many ways. It could mean creating, reading, updating, or even deleting a resource. When it comes to setting up permissions for users, remember that you have to set up permissions around the entire list of potential actions. Ignoring this can lead to insecure resources—or even clients having partial control over resources they should completely own.

Conclusion

In conclusion, remember that both HTTP 401 and 403 error codes are valid responses that your platform might send back. Just because your users (or you) are experiencing either of these errors, it doesn't mean it's an automatic problem on the platform's side. To solve these problems, start by trying to understand the source of the problem. Then, using the information about both response codes, figure out if there is actually a problem. If there is, you now know where to look for the solution.

Book a free Policy Workshop to discuss your requirements and get your first policy written by the Cerbos team