Top 5 API authentication pitfalls and how to avoid them

By Jason Kent

The use of application programming interfaces (APIs) has exploded in recent years as enterprises deploy mobile apps, containers, serverless computing, microservices, and expand their cloud presence. As a result, many APIs are hastily developed and deployed, leading to the persistence of coding errors – with poor authentication being one of the top offenses.

Attackers are eager to exploit these authentication security gaps and use them to gain unauthorized access to applications and exfiltrate data for malicious purposes. This can not only lead to significant data loss, but also threaten the integrity of a brand.

Consequently, many development teams are closely examining their API security posture to prevent becoming the next big headline. Let’s take a look at the five most common pitfalls of API authentication and best practices for how to avoid and remediate them.

#1: Unauthenticated APIs

Unauthenticated APIs are one of the worst mistakes that can be made in a public-facing API, especially if it handles sensitive business information or confidential data. So, why would someone intentionally create an unauthenticated API in the first place?

Development teams will usually create unauthenticated APIs as an intermediate step to support legacy applications, as they may not always be compatible with the latest authentication method of a particular use case or organization. While this may seem convenient at the time, if someone forgets to document the necessary work or leaves the team, an unauthenticated API can end up in production for months without anyone realizing it.

Oscar Wilde once famously said: “When you assume, you make an ass out of U and Me.” And this couldn’t be any truer when it comes to API security. Development teams should never assume that the people who opened the gate for a one-time exception will return to close it before deployment. Doing so poses a significant risk and can allow cybercriminals to exploit the security gaps. The best way to avoid these situations is to never deploy an API without proper authentication – publicly or internally.

#2: Non-Null Value Authentication Tokens

Authentication tokens—which are values used to authenticate and authorize a user or application—play a crucial role in preventing unauthorized access to protected resources and sensitive data. Without a valid token, the API will deny the request and the user or application won’t be able to gain access.

However, APIs that don’t verify authentication token values and only check for the presence of a token are frequently deployed in production. This means that attackers can gain access by including any auth token in their API request since the application only checks for the presence of an auth token, and not its actual value. Similar to unauthenticated APIs, this method was originally intended for temporary use during development. As a best practice, always give a token value for both internal and external APIs.

#3: Unauthorized APIs

Another common pitfall is deploying APIs with only authentication and no authorization. Part of the reason this happens is because organizations believe that implementing user authentication alone is sufficient, and that there’s little advantage to checking a user’s authorization privileges in an API request. This means that any user who is authenticated—legitimate or not—can bypass authorization privileges by enumerating user identifiers. For example, if a user logs in to view their profile and the backend does not enforce strong authorization checks, they can access information over the same API by changing their user identifier.

This type of attack is rarely detected, which means that cybercriminals can take advantage of the long dwell time to search around until they discover and can extract sensitive data. To mitigate the risk of these types of enumeration threats, it’s best to use randomly generated alpha-numeric identifiers.

#4: Token Proliferation

In distributed development environments, it’s common for app development teams to deploy their own type of API authentication, which in turn creates an API that can accept authentication tokens in multiple ways. This results in a fragmented approach that not only makes it harder for teams to manage these APIs, but also increases their risk of compromise over time.

If there is a potential vulnerability in any single authentication request, it can jeopardize the security of the entire API. There is also a higher chance that someone will overlook one of the multiple authentication approaches during future updates – leaving the API more susceptible to attacks. A potential vulnerability in any single authentication request can jeopardize the security of the entire API. It’s also much more likely that future updates will overlook one of the many authentication approaches, making your API more vulnerable to attacks.

At a bare minimum, it’s crucial for teams to identify APIs during runtime and flag any fragmented authentication issues with them once detected. Additionally, teams can enforce a consistent approach by using a set specification such as OpenAPI/Swagger and conducting functionality-based testing before deployment.

#5: Improper Authorization Logic

APIs that have improper authorization logic can allow access to higher-privilege environments by accepting authentication tokens generated in lower-privilege environments. This can quickly turn into a serious problem if an attacker uses this tactic to gain access to production or other sensitive environments.

For example, a cybercriminal could obtain an authentication token from staging and then replay it to the production server. A weak authorization implementation would then grant access since the token is technically valid, but for the wrong environment. To prevent these types of risks, development teams should use authentication scopes or other identity enforcement mechanisms to establish and enforce a proper privilege hierarchy for users.

Given the sheer number of APIs being deployed every day, it’s nearly impossible for any organization to catch every error. It requires security and development teams to work together — following well-established API standards and implementing security practices during the development process to lower the occurrence of authentication and authorization errors.