Api ошибка 403

Short description

An HTTP 403 response code means that a client is forbidden from accessing a valid URL. The server understands the request, but it can’t fulfill the request because of client-side issues.

API Gateway APIs can return 403 responses for any of the following reasons:

Resolution

Consider the source of the error

If the 403 error was reported from other resources, there might be another cause for the error. For example:

• If the error was reported in a web browser, then that error might be caused by an incorrect proxy setting. The proxy server returns a 403 error if HTTP access isn’t allowed.
• If there’s another AWS service in front of the API, then that service can reject the request with a 403 error in the response. For example: Amazon CloudFront.

Identify what’s causing the error

If you haven’t done so already, set up Amazon CloudWatch access logging for your API. Then, view your API’s execution logs in CloudWatch to determine if requests are reaching the API.

Note: HTTP APIs don’t support execution logging. To troubleshoot 403 errors returned by a custom domain name that requires mutual TLS and invokes an HTTP API, you must do the following:

1.    Create a new API mapping for your custom domain name that invokes a REST API for testing only.

2.    Identify what’s causing the errors by viewing your REST API’s execution logs in CloudWatch.

3.    After the error is identified and resolved, reroute the API mapping for your custom domain name back to your HTTP API.

Confirm that the requested resource exists in the API definition

Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.

Verify the following using either the API Gateway console or the AWS CLI:

• The API is deployed with the latest API definition.
• The requested resource exists in the API definition.

Use curl to get request and response details

If the error can be reproduced, use the curl -v command to get more details between the client and the API similar to the following:

curl -X HTTP_VERB -v https://{api_id}.execute-api.{region}.amazonaws.com/{stage_name}/{resource_name}
Note: For more information, see the curl project website.
Verify that the request header is correct
If the error is the result of an API key that’s not valid, then verify that the «x-api-key» header was sent in the request.
Verify that the DNS setting on any interface Amazon VPC endpoints is set correctly
Note: Confirm the following for APIs invoked from an Amazon VPC that has an interface VPC endpoint only.
Verify that the DNS setting of the interface endpoint is set correctly based on the type of API that you’re using.
Keep in mind the following:

To invoke a Regional API from inside an Amazon VPC, private DNS names must be deactivated on the interface endpoint. Then, the endpoint’s hostname can be resolved by a public DNS. For more information, see Creating a private API in Amazon API Gateway.
To invoke a private API from inside an Amazon VPC using the API’s private DNS name, private DNS names must be activated on the interface endpoint. Then, the interface endpoint’s hostname can be resolved to the Amazon VPC’s local subnet resources. For more information, see How to invoke a private API.

Note: You don’t need to set up a private DNS if you’re invoking the private API using either of the following:

The private API’s public DNS name.

-or-

An Amazon Route 53 alias.

Review the API’s resource policy
Review your API’s resource policy to verify the following:

(For APIs invoked from an Amazon VPC with an interface VPC endpoint) The API’s resource policy grants the Amazon VPC or the interface endpoint access to the API.
The resource policy’s resource specifications and formatting are correct.

Note: There’s no validation of the resource specification when saving a resource policy. For examples, see API Gateway resource policy examples.
The caller is allowed to invoke the API endpoint by the authentication type that you’ve defined for the API. For more information, see How API Gateway resource policies affect authorization workflow.

Review HTTP request and response messages
Reproduce the error in a web browser, if possible. Then, use the browser’s network tools to capture the HTTP request and response messages and analyze them to determine where the error occurred.
Note: For offline analysis, save the messages in an HTTP Archive (HAR) file.



  


                       
  





Related information
Common errors — Amazon API Gateway
How do I allow only specific IP addresses to access my API Gateway REST API?
How do I troubleshoot issues when connecting to an API Gateway private API endpoint?
How do I turn on Amazon CloudWatch Logs for troubleshooting my API Gateway REST API or WebSocket API?

When building APIs for the first time, it is important to understand error status codes and how they impact the overall performance of the API. Error status codes are essential for ensuring that the API is functioning correctly, communicating errors and warnings to the user or system, and providing a seamless experience.

It is important to understand the different types of error status codes, what they mean, and how to interpret them so that your API will function properly.

This blog post will explore the various API error status codes and how to interpret them when building APIs for the first time.

It will provide a comprehensive discussion on the different types of error codes and the best practices for handling them, as well as provide a few tips to help make your API building experience as smooth as possible.

• What are API error Codes?
• Client-side status code
  1. 404 — Not Found
  2. 401 — Unauthorized
  3. 403 — Forbidden
  4. 400 — Bad Request
  5. 429 — Too Many Requests
• Server-side status code
  1. 500 — Internal Server Error
  2. 502 — Bad Gateway
  3. 503 — Service Unavailable
  4. 504 — Gateway Timeout
  5. 501 — Not Implemented
• Best practices for handling API Error codes

What are API error Codes?

API error codes are standardized status codes that are returned by an API (Application Programming Interface) in response to a client’s request. These codes are used to indicate whether the requested operation was successful or not, and if not, to provide information on the type of error that occurred.

API error codes are typically three-digit numbers, with the first digit indicating the general category of the error, and the remaining two digits specifying the particular error within that category. For example, a 404 error code is a common error that indicates the requested resource was not found on the server.

By providing standardized error codes, APIs can communicate more effectively with clients and developers, and allow them to quickly diagnose and address any issues that arise during the use of the API.

For example, Suppose a client sends a request to an API to retrieve information about a specific resource, such as a user profile, but the API is unable to find that resource. In this case, the API may return a 404 error code, with a message indicating that the requested resource was not found.

The 404 error code is a standardized HTTP status code, which indicates that the server was unable to find the requested resource. The first digit «4» indicates that the error falls under the category of client errors, meaning that the error was caused by an issue with the client’s request, rather than an issue with the server. The remaining two digits «04» specify the specific error within that category, in this case, «not found».

The client can then use this information to understand that the requested resource was not found, and take appropriate action, such as displaying an error message to the user or retrying the request with different parameters.

There are two types of error status codes when you build an API for the first time.

1. Client-side Status Code
2. Server-side Status Code

Client-side Status Code

Client-side status codes are HTTP response codes that are generated by a client’s web browser in response to a server’s attempt to fulfill the client’s request. These codes are used to communicate information about the status of the request to the client, and they can help the client to take appropriate action based on the response.

The 4XX series of status codes often refers to client-side failures, though they can also result from modifications to the API. The top 5 client-side status error codes are listed below, along with explanations of how to fix them.

There are 5 common client-side status codes when you build an API:

1. 400 — Bad Request

The 400 Bad Request error is an HTTP response status code that indicates that the server cannot understand the request sent by the client because it was malformed or incomplete. This means that the server is unable to process the request and return the desired response.

Ways to fix the 400 — Bad Request error

1. Check the URL: Make sure the URL you’re trying to access is correct and complete.
2. Clear your cache and cookies: Clearing your browser’s cache and cookies can sometimes help fix the 400 error.
3. Check your request syntax: Double-check that your request syntax is correct, including all necessary headers and parameters.
4. Check for outdated software: Make sure that your web browser, operating system, and other software are up-to-date.
5. Disable browser extensions: Try disabling any browser extensions that may be interfering with your web requests.
6. Contact the website owner: If you’re trying to access a specific website, you can try contacting the website owner or technical support team for assistance.
7. Try a different browser or device: If you’re still having trouble after trying the above steps, you can try accessing the website from a different browser or device.

The client request has not been fulfilled because it does not contain proper authentication credentials for the requested resource, as indicated by the HyperText Transfer Protocol (HTTP) 401 Unauthorized response status code.

Because the client request does not contain proper authentication credentials for the requested resource, the HyperText Transfer Protocol (HTTP) 401 Unauthorized response status code indicates that the client request has not been fulfilled.

This error indicates that the website or web application was unable to authenticate the request that was made. Fortunately, this problem may typically be quickly fixed.

Ways to fix 401 — Unauthorized Error

• Verify that you are using a valid user ID and password to log in.
• It may be worthwhile to momentarily disable password security for the troublesome area of your website if you’re a webmaster trying to fix the 401 issue.
• It may be worthwhile to momentarily disable password security for the troublesome area of your website if you’re a webmaster trying to fix the 401 issue. Clear it!

3. 403 — Forbidden

Although the server recognizes the request, it will not grant access, as shown by the HTTP response status code 403 Forbidden. For the 403 Forbidden status code, re-authenticating has no effect, even though this status is comparable to 401. Such as insufficient privileges to a resource, the access is connected to the application logic.

Simply put, it indicates that the website’s content you’re seeking to access is being banned for a specified reason. Although the cause could be something in your power, the content owner or server is more likely to be to blame.

A request that the server cannot accept results in a 403 Forbidden error. This frequently happens because of firewall rules that categorically forbid making this particular request, but other settings, including permissions, may also restrict access based on user privileges.

Ways to fix 403 — Forbidden error

• If you’ve made it this far and none of the previous fixes have worked, there’s a good possibility that the issue is the result of a malfunctioning or incompatible plugin. Try disabling plugins.
• Verify the name of the homepage on your website; it should be index.html or index.php. The first and easiest is to change the homepage’s name to index.html or index.php.

4. 404 — Not Found

A website user will be informed if a requested page is unavailable with the status code 404. The Hypertext Transfer Protocol response codes on the web include 404 and various response status codes. The 404 error number indicates that a client’s requested webpage was not found by the server.

These happen when a page cannot be located. If the URL is typed incorrectly or the page has been erased, this may occur. These 400 errors show that the request cannot be processed by the server. This may occur if there is a coding issue or if the website is unavailable for maintenance.

Ways to fix 404 — Page Not Found Error

• Open a new window and try to close the current one.
• erase the cache. Delete the history and data from your browser.
• To be sure you typed in the proper website address in the search bar, double-check the URL.
• Make sure your website doesn’t include any broken links.

5. 429 — Too Many Requests

When a user sends too many requests in a short period, the HTTP 429 Too Many Requests response status code shows this («rate limiting»). This answer may have a Retry-After header stating how long it should be before a fresh request is made.

The lack of resources to handle so many concurrent requests is the main reason behind 429 errors. If this error, for instance, appears on a hosting server, it may indicate that the package you are using has a cap on the number of requests you are permitted to submit.

Ways to fix 429 — Too many requests error

• The next time you come, the browser can load the website more quickly thanks to cached data. But, as this data builds up, the 429 error may appear. Thus, the first step is to empty the cache on your browser.
• Conflicts may also result from WordPress themes with poor coding. Switching to a default WordPress theme is the simplest method to address this problem.

Server-side Status Code

Server-side status codes are HTTP response codes that are generated by a web server in response to a client’s request for a resource. These status codes provide information about the status of the server’s attempt to fulfill the request, and they help to ensure that the client and server can communicate effectively.

The 5XX group of status codes typically returns in response to a server error, but if the server misses an invalid API call that ought to produce a 4XX answer, it may also return a 5XX error.

1. 500 — Internal Server Error

The HyperText Transfer Protocol (HTTP) 500 Internal Server Error server error response code denotes that the request could not be processed by the server due to an unexpected condition. This error message is an all-purpose «catch-all» message.

Since the 500 Internal Server Error is a server-side issue, it is most likely not your computer or internet connection that is at fault, but rather the server hosting the website. Although unlikely, there could be a problem on your end, in which case you can try the following: Refresh the website.

When a server-side issue prohibits Apache from handling a request and providing a suitable response, Apache returns a 500 Internal Server Error. This may be the result of several factors, including flawed code, insufficient file permissions, and missing files mentioned in the code.

Ways to fix 500 — Internal Server Error:

• Attempt refreshing the page. The website may return immediately if the host or server is just overloaded.
• Themes and plugins from unofficial sources might easily result in 500 internal server issues. Deactivate them.

2. 501 — Not Implemented

The server does not support the functionality required to complete the request if the HyperText Transfer Protocol (HTTP) 501 Not Implemented server error response code is returned. The Retry-After header, which notifies the requester when to check back to see if the functionality is supported by then, may also be sent by this status.

You can’t fix the problem yourself because it’s a server-side error; it needs to be fixed by the server and website management.

An HTTP error message, also known as an HTTP status code, is returned by a browser when it accesses a page and discovers something that doesn’t operate properly. A problem on the server is indicated if the message’s code begins with a 5.

This indicates that anything on the server’s end of the website is malfunctioning and preventing a full page load. The root causes of this problem, however, can vary.

Ways to fix 501 — Not Implemented Error:

• Malware or viruses on the computer could be the cause of Error 501. Thus, it’s crucial to do a comprehensive scan of your antivirus software and maintain it updated.
• Checking the server’s log files to see if any error messages can aid with the problem can be another idea for resolving it.

3. 502 — Bad Gateway

A 502 bad gateway message denotes that a server received a faulty answer from another server. In essence, you have established a connection with some sort of temporary device (such as an edge server) that should fetch all the information required to load the page.

The notice identifies the issue as anything with that process that went wrong. It denotes a server issue rather than one with your device, router, or internet connection. There’s a good chance that other website visitors are having the same issue.

Ways to fix 502 — Bad Gateway Error

• Deciding to re-route your internet traffic over a virtual private network (VPN) can assist you to figure out whether the connection to the site is having problems because of your ISP or something else.
• Clearing the browser’s cache might help if refreshing the browser a few times doesn’t work.
• Check the web server logs from the time the error occurred.

4. 503 — Service Unavailable

An HTTP response status code of 503 Service Unavailable indicates that although your web server is operational, it is now unable to handle a request. It’s challenging to determine the precise cause of the problem because the error message is only a general one.

You are not at fault because a 503 error on the HTTP protocol usually signifies that the server is having problems. But, you may troubleshoot and resolve the issue by following a few straightforward actions. When you get a 503 service unavailable error message, you could be left scratching your head and wondering what went wrong.

Ways to 503 — Service Unavailable Error:

• A server employs Memory, CPU, I/O, entry processes, and website inodes as resources. You can determine whether the problem is connected to resource limitations by looking at these metrics.
• Several web hosting typically gives their users automatic upgrades. You have the opportunity to change the server configuration settings and turn off automatic updates.

5. 504 — Gateway Timeout

The 504 «Gateway Timeout» Error denotes that the browser attempted to send an HTTP request to the server but was unable to do so because it did not receive a timely response from another server. You may usually fix it by refreshing the website.

A 504 Gateway Timeout Error denotes that your web server did not immediately receive a response from an upstream server when it attempted to load one of your web pages. Simply said, the communication between your web servers isn’t happening swiftly enough.

Ways to fix 504 — Gateway Timeout Error:

• Try opening the WordPress website in incognito mode and using a different browser.
• An alternative computer, network connection, or mobile device might be able to load the page. To determine whether the issue is with the hardware or the internet connection, you may also try restarting the network devices.

Discover the secrets of HTTP status codes with our Complete Guide! Learn how to use them effectively to communicate with clients and servers, and how to handle errors gracefully.

Best practices for handling API Error Codes

1. Use standardized error codes: Use well-defined error status codes consistent with industry standards and HTTP specifications. This can make it easier for clients to understand and handle errors.
2. Provide informative error messages: Include informative and precise error messages and error codes to help clients understand the reason for the error and what action they can take to resolve it.
3. Be consistent: Ensure consistency in the format and content of error messages and error status codes across all API endpoints to avoid confusion and simplify client error handling.
4. Use appropriate HTTP methods: Use appropriate HTTP methods to indicate the nature of the request and the desired action. For example, use GET for retrieving data and POST for creating new resources.
5. Implement retries: Allow clients to retry failed requests after a specified interval to reduce the impact of temporary network or server issues.
6. Log errors: Log all API errors, including error codes, error messages, and any relevant details, to help diagnose and troubleshoot issues.
7. Use versioning: Use versioning to indicate API changes and allow clients to migrate to new versions at their own pace without disrupting existing applications.

Here’s an example of how to handle API errors in a Node.js application using the Express framework:

const express = require('express');
const app = express();

app.get('/users/:id', (req, res) => {
  const userId = req.params.id;
  if (!isValidUserId(userId)) {
    const error = new Error('Invalid user ID');
    error.status = 400; // Set the HTTP status code
    return next(error);
  }
  // Continue with the normal request handling
  // ...
});

// Error handler middleware
app.use((err, req, res, next) => {
  const statusCode = err.status || 500; // Default to 500 if status code not set
  res.status(statusCode).json({
    message: err.message
  });
});

// Helper function to validate user IDs
function isValidUserId(id) {
  // Check if ID is a non-empty string of digits
  return /^\d+$/.test(id);
}

In this example, the API endpoint /users/:id accepts a request to retrieve a user’s information based on their ID. The isValidUserId function is used to validate the user ID, and if it is found to be invalid, an error is thrown with a message of «Invalid user ID» and a status code of 400. The error is then passed to the error handler middleware using the next function, which sets the appropriate status code and sends a JSON response with the error message.

The error handler middleware is a catch-all middleware that handles any errors that occur in the application. It extracts the status code and error message from the error object and sends a JSON response to the client with that information.

By following this pattern, you can ensure that any errors that occur during the handling of an API request are properly handled and communicated to the client in a consistent and informative manner.

Conclusion

Any issue that prevents access to the website should be resolved as quickly as possible. This is because while your page is down, your visitors are unable to access your material, which is bad for your business. After all, you could lose both the visit and a potential client.

The detrimental effects of unavailability on the SEO strategy are one of the key issues they create. This is due to Google periodically crawling the website’s pages for indexing. Hence, it will produce an error message if it tries to access the website and discovers that it is not available.

Refreshing the page and clearing the cache are two simple things that provide reliable solutions for any type of error. Hence, take into account the potential reasons for the problem and the suggested fixes to your website.

Atatus API Monitoring and Observability

Atatus provides Powerful API Observability to help you debug and prevent API issues. It monitors the consumer experience and is notified when abnormalities or issues arise. You can deeply understand who is using your APIs, how they are used, and the payloads they are sending.

Atatus’s user-centric API observability tracks how your actual customers experience your APIs and applications. Customers may easily get metrics on their quota usage, SLAs, and more.

It monitors the functionality, availability, and performance data of your internal, external, and third-party APIs to see how your actual users interact with the API in your application. It also validates rest APIs and keeps track of metrics like latency, response time, and other performance indicators to ensure your application runs smoothly.

Try your 14-day free trial of Atatus!

Assume your Web API is protected and a client attempts to access it without the appropriate credentials. How do you deal with this scenario? Most likely, you know you have to return an HTTP status code. But what is the more appropriate one? Should it be 401 Unauthorized or 403 Forbidden? Or maybe something else?

As usual, it depends 🙂. It depends on the specific scenario and also on the security level you want to provide. Let’s go a little deeper.

If you prefer, you can watch a video on the same topic:

Web APIs and HTTP Status Codes

Before going into the specific topic, let’s take a quick look at the rationale of HTTP status codes in general. Most Web APIs are inspired by the REST paradigm. Although the vast majority of them don’t actually implement REST, they usually follow a few RESTful conventions when it comes to HTTP status codes.

The basic principle behind these conventions is that a status code returned in a response must make the client aware of what is going on and what the server expects the client to do next. You can fulfill this principle by giving answers to the following questions:

• Is there a problem or not?
• If there is a problem, on which side is it? On the client or on the server side?
• If there is a problem, what should the client do?

This is a general principle that applies to all the HTTP status codes. For example, if the client receives a 200 OK status code, it knows there was no problem with its request and expects the requested resource representation in the response’s body. If the client receives a 201 Created status code, it knows there was no problem with its request, but the resource representation is not in the response’s body. Similarly, when the client receives a 500 Internal Server Error status code, it knows that this is a problem on the server side, and the client can’t do anything to mitigate it.

In summary, your Web API’s response should provide the client with enough information to realize how it can move forward opportunely.

Let’s consider the case when a client attempts to call a protected API. If the client provides the appropriate credentials (e.g., a valid access token), its request is accepted and processed. What happens when the client has no appropriate credentials? What status code should your API return when a request is not legitimate? What information should it return, and how to guarantee the best security experience?

Fortunately, in the OAuth security context, you have some guidelines. Of course, you can use them even if you don’t use OAuth to secure your API.

«The basic principle behind REST status code conventions is that a status code must make the client aware of what is going on and what the server expects the client to do next»

Tweet This

When to Use 400 Bad Request?

Let’s start with a simple case: a client calls your protected API, omitting a required parameter. In this case, your API should respond with a 400 Bad Request status code. In fact, if that parameter is required, your API can’t even process the client request. The client’s request is malformed.

Your API should return the same status code even when the client provides an unsupported parameter or repeats the same parameter multiple times in its request. In both cases, the client’s request is not as expected and should be refused.

Following the general principle discussed above, the client should be empowered to understand what to do to fix the problem. So, you should add in your response’s body what was wrong with the client’s request. You can provide those details in the format you prefer, such as simple text, XML, JSON, etc. However, using a standard format like the one proposed by the Problem Details for HTTP APIs specifications would be more appropriate to enable uniform problem management across clients.

For example, if your client calls your API with an empty value for the required data parameter, the API could reply with the following response:

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Content-Language: en

{
  "type": "https://myapi.com/validation-error",
  "title": "Validation error",
  "detail": "Your request parameters are not valid.",
  "invalid-params": [
    {
      "name": "data",
      "reason": "cannot be blank."
    }
  ]
}

When to Use 401 Unauthorized?

Now, let’s assume that the client calls your protected API with a well-formed request but no valid credentials. For example, in the OAuth context, this may fall in one of the following cases:

• An access token is missing.
• An access token is expired, revoked, malformed, or invalid for other reasons.

In both cases, the appropriate status code to reply with is 401 Unauthorized. In the spirit of mutual collaboration between the client and the API, the response must include a hint on how to obtain such authorization. That comes in the form of the WWW-Authenticate header with the specific authentication scheme to use. For example, in the case of OAuth2, the response should look like the following:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

You have to use the Bearer scheme and provide the realm parameter to indicate the set of resources the API is protecting.

If the client request does not include any access token, demonstrating that it wasn’t aware that the API is protected, the API’s response should not include any other information.

On the other hand, if the client’s request includes an expired access token, the API response could include the reason for the denied access, as shown in the following example:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                  error="invalid_token",
                  error_description="The access token expired"

When to Use 403 Forbidden?

Let’s explore a different case now. Assume, for example, that your client sends a request to modify a document and provides a valid access token to the API. However, that token doesn’t include or imply any permission or scope that allows the client to perform the desired action.

In this case, your API should respond with a 403 Forbidden status code. With this status code, your API tells the client that the credentials it provided (e.g., the access token) are valid, but it needs appropriate privileges to perform the requested action.

To help the client understand what to do next, your API may include what privileges are needed in its response. For example, according to the OAuth2 guidelines, your API may include information about the missing scope to access the protected resource.

Try out the most powerful authentication platform for free.Get started →

Security Considerations

When you plan how to respond to your client’s requests, always keep security in mind.

How to deal with response details

A primary security concern is to avoid providing useful information to potential attackers. In other words, returning detailed information in the API responses to attempts to access protected resources may be a security risk.

For example, suppose your API returns a 401 Unauthorized status code with an error description like The access token is expired. In this case, it gives information about the token itself to a potential attacker. The same happens when your API responds with a 403 Forbidden status code and reports the missing scope or privilege.

In other words, sharing this information can improve the collaboration between the client and the server, according to the basic principle of the REST paradigm. However, the same information may be used by malicious attackers to elaborate their attack strategy.

Since this additional information is optional for both the HTTP specifications and the OAuth2 bearer token guidelines, maybe you should think carefully about sharing it. The basic principle on sharing that additional information should be based on the answer to this question: how would the client behave any differently if provided with more information?

For example, in the case of a response with a 401 Unauthorized status code, does the client’s behavior change when it knows that its token is expired or revoked? In any case, it must request a new token. So, adding that information doesn’t change the client’s behavior.

Different is the case with 403 Forbidden. By informing your client that it needs a specific permission, your API makes it learn what to do next, i.e., requesting that additional permission. If your API doesn’t provide this additional information, it will behave differently because it doesn’t know what to do to access that resource.

Don’t let the client know…

Now, assume your client attempts to access a resource that it MUST NOT access at all, for example, because it belongs to another user. What status code should your API return? Should it return a 403 or a 401 status code?

You may be tempted to return a 403 status code anyway. But, actually, you can’t suggest any missing permission because that client has no way to access that resource. So, the 403 status code gives no actual helpful information. You may think that returning a 401 status code makes sense in this case. After all, the resource belongs to another user, so the request should come from a different user.

However, since that resource shouldn’t be reached by the current client, the best option is to hide it. Letting the client (and especially the user behind it) know that resource exists could possibly lead to Insecure Direct Object References (IDOR), an access control vulnerability based on the knowledge of resources you shouldn’t access. Therefore, in these cases, your API should respond with a 404 Not Found status code. This is an option provided by the HTTP specification:

An origin server that wishes to «hide» the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).

For example, this is the strategy adopted by GitHub when you don’t have any permission to access a repository. This approach avoids that an attacker attempts to access the resource again with a slightly different strategy.

How to deal with bad requests

When a client sends a malformed request, you know you should reply with a 400 Bad Request status code. You may be tempted to analyze the request’s correctness before evaluating the client credentials. You shouldn’t do this for a few reasons:

• By evaluating the client credentials before the request’s validity, you avoid your API processing requests that aren’t allowed to be there.
• A potential attacker could figure out how a request should look without being authenticated, even before obtaining or stealing a legitimate access token.

Also, consider that in infrastructures with an API gateway, the client credentials will be evaluated beforehand by the gateway itself, which doesn’t know at all what parameters the API is expecting.

The security measures discussed here must be applied in the production environment. Of course, in the development environment, your API can provide all the information you need to be able to diagnose the causes of an authorization failure.

Recap

Throughout this article, you learned that:

• 400 Bad Request is the status code to return when the form of the client request is not as the API expects.
• 401 Unauthorized is the status code to return when the client provides no credentials or invalid credentials.
• 403 Forbidden is the status code to return when a client has valid credentials but not enough privileges to perform an action on a resource.

You also learned that some security concerns might arise when your API exposes details that malicious attackers may exploit. In these cases, you may adopt a more restricted strategy by including just the needed details in the response body or even using the 404 Not Found status code instead of 403 Forbidden or 401 Unauthorized.

The following cheat sheet summarizes what you learned: