API Security Best Practices: Avoiding the Top 5 Authentication Errors

API authentication errors are listed as the top two threats outlined in the OWASP API Security Top 10, both of which can be traced back to many of the recent publicly disclosed API security incidents. Unauthenticated APIs, too many API tokens, and improper API authentication logic are just a few of the errors found in customer environments, all of which can lead to unauthorized access to back end resources by an attacker. Listed below are the top 5 API authentication errors and best practices on how to eliminate them before they become security incidents.

The OWASP API Security Top 10 provides a good framework for the kind of risks to evaluate the API inventory against. They are listed in a top 10 form for a reason – the most common and severe are at the top. For example, the first two in the list deal with Authentication and Authorization, both of which can be traced back to some of the recent API incidents mentioned above, and commonly found in our own customer environments.

#1: Unauthenticated APIs

Unauthenticated APIs are by far the worst things to detect in a public-facing API. This is especially true for APIs that handle essential business information that may contain information subject to regulatory compliance like PCI or PHI.

One common reason cited for the lack of authentication in a public-facing API handling necessary business data is that the API was intentionally left unauthenticated in the past to support a legacy application that did not support authentication. That may have been the case at one time, but that doesn’t mean the API should remain open. Today, many uses (including external and internal) would be accessing the API completely openly. People who knew the history of the older limitations may have left the company, and as a result, the enterprise would need to scramble and close this gap now. It is never acceptable to open the gate to make room for such exceptions because very rarely do people go back and close the gate at a later point in time.

Best Practice: NEVER deploy an unauthenticated API – internal or public-facing.

#2: APIs Using Non-Null Value Auth Tokens

Hard though it may be to imagine, it is common to find APIs that do not implement any authentication using the auth token at all, but rather only check for the existence of one in the request. This issue is often more shocking to find than even the lack of authentication in an API, because this allows users to access the resource by merely passing an auth token in an API request. The actual value of the token does not matter, since the application merely checks for the presence of an auth token – any auth token – in the request.

It’s hard to think of a good reason why APIs may have been developed with this approach. Perhaps they lacked the time necessary to implement the authentication logic in the backend application? Unfortunately, it doesn’t take much effort or time for an attacker to exploit these APIs. They only need to send in a non-null value for the auth token, and the API request will be successfully processed. The use of non-null-value token should never be allowed. Ever. It introduces a significant risk of being used “temporarily” but never being removed.

 Best Practice: ALWAYS assign a token value for internal or public-facing APIs.

#3: APIs are Authenticated, but not Authorized

APIs with only authentication and no authorization is another common pitfall. Caused partly by the notion that implementing user authentication is “good enough”, there is little benefit to reap by validating the user’s authorization privileges. The downside is that this allows users to access resources that don’t belong to them.

For example, suppose a user logs in to check their profile, and the backend is not enforcing strong authorization checks. The user will be able to “sniff” around and grab information over the same API by changing their user identifier. In this all-too-common API risk, authenticated users can exfiltrate information for many other users by simply enumerating the identifiers.

This issue gets even worse if the identifiers are simple numeric values like 6-digit numbers, which the attacker can easily enumerate. The very minimum recommendation is to use randomly generated alpha-numeric identifiers to at least mitigate, (but does not eliminate), the risk of such enumeration attacks.

Best Practice: ALWAYS implement strong authorization mechanisms to complement strong authentication.

#4: API Token Proliferation

It is common for the app development team to support different types of authentication integration with different consumers of their APIs. This ends up resulting in a fragmented authentication approach for the API that becomes hard to manage for app owners.

For example, consumer A might send an API token called X-api-token in the request header to authenticate themselves to the app. Instead, consumer B of the same API might send their API token in a request param called api-key. A third consumer C might send theirs in the Authorization header.

This divergent approach results in the API accepting auth tokens in a variety of ways. A potential weakness in any of those approaches, similar to the ones we saw above, can compromise access for all of them. Our recommendation is to enforce consistency in an API definition such as a Swagger specification, and then test for the result to eliminate the risk before publication. At the very minimum, it is important to discover your APIs in runtime and detect if you have such a fragmented auth issue with any of them.

 Best Practice: Enforce CONSISTENCY using an API spec framework and go beyond basic pen testing using functionality-based test plans.

#5: APIs With Improper Authorization Logic

APIs with improper authorization logic allows access to higher-privilege environments like production by accepting auth tokens produced in lower-privilege environments such as dev or staging. This can rapidly escalate to a major vulnerability if users gain easy access to sensitive business data in the production environment.

A savvy threat actor may be able to grab an auth token from a lower environment and replay that to the production server. A poor implementation of auth would allow such access since the auth token itself might be valid, but for the wrong environment. To remediate this risk, the authorization scope of auth tokens needs to be appropriately limited to the resources that are allowed to be accessed.

Best Practice: Use OAuth Scopes or other tools to create and implement a well-designed authorization backend.

Summary

API Authentication tokens are quite literally the keys to your app kingdom. These 5 authentication weaknesses were all found in our customer environments, leaving their APIs vulnerable to threat actors breaking into their application and exfiltrating information that they are not authorized to access.

It is important to create an inventory and analyze public-facing APIs to find authentication gaps before they are published or discovered by threat actors. The authentication and authorization issues discussed in this blog can be mapped back to one or more of the following OWASP API Security Top 10 Threats.

• API1: 2019 Broken Object Level Authorization
• API2: 2019 Broken User Authentication
• API5: 2019 Broken Function Level Authorization

Using the OWASP top 10 lists in conjunction with an API specification framework where authentication and authorization requirements are defined and tracked can uncover API coding security gaps for remediation to ensure your APIs and the resources they connect to are secure.