API Security Best Practices: API Discovery Insights

API security best practices dictate that you first need to discover all of your APIs – managed, unmanaged, third-party, shadow and zombie – both external and internal. With the understanding that you cannot protect what you cannot see, most security professionals are often surprised by both the number of APIs actually found and the associated risks, and potential vulnerabilities uncovered. Following on my recent Top 5 API Authentication Pitfalls blog, today’s topic is the five API discovery insights from recent customer engagements with Fortune-50 financial services, telecom, and retail organizations.

Security professionals are often surprised by both the number of APIs actually found and the risks introduced by common API errors. Following on my recent Top 5 API Authentication Pitfalls blog, today’s topic is the five API discovery insights from recent customer engagements with Fortune-50 financial services, telecom, and retail organizations.

API Discovery Insight #1: Many APIs Are Simply Unauthenticated

When told that your neighbor’s house was cleaned out by burglars because they left their doors and windows open, your first reaction is likely going to be of skepticism and disbelief. Unlocked doors and windows are physically analogous to APIs without authentication. In every API security customer engagement to date, we find APIs that are unauthenticated or using weak forms of authentication which, as shown in the many API breaches of 2021 allow willful attackers to easily bypass.

During the API discovery and During the API discovery and inventory phase, security teams should expect to see APIs with authentication gaps as the most common finding and they should be prepared to initiate the remediation process with development.

Insight #2: Sensitive Data Values Are Not Getting Masked

Many cybersecurity professionals hope that APIs handling sensitive data fields like payment or billing information are using appropriate security or privacy practices. In other words, they hope that these APIs are encrypting or at least masking these values in requests and responses.

As we know, hope is not a good strategy.

In almost every API security engagement to date, we have discovered sensitive data in clear text in requests or responses and APIs handling sensitive fields like names, addresses, billing information, payment card details, and other forms of compliance-sensitive values that are not masked nor encrypted. Sensitive data exposed in API transactions is a very attractive target for attackers. The discovery insight for security professionals is that they should be prepared to find APIs handling sensitive fields improperly and they should help development remediate the issue quickly.

Insight #3: API Developers Expose More Information Than Needed

Another common API discovery surprise for security professionals is to see APIs exposing far more data in API responses than their specifications demanded. Many modern APIs have corresponding specifications, often written in formats like OpenAPI/Swagger or RAML, to share the details of the API request and response syntax with clients. The specifications are often (or should be) carefully pruned by API owners to include only the fields that clients should be allowed to access. Fields that are deemed sensitive or to be used for internal use only are often (or should be) culled out of the specifications.

But that doesn’t stop API developers from implementing support in the actual APIs to respond with these additional fields. A common reason for this is that support teams might have requested these additional values from the API owner since they might be useful for troubleshooting purposes. Once implemented, both the support team and attackers will benefit from the values being returned to all valid API clients.

In the figure above, the API specification was designed to only expose user-name, profile-id, group and region to be returned in API responses. But the API discovery phase exposed additional fields, including some handling sensitive data (like authz-code or authorized-budget) or exploitable by attackers for privilege-escalation (like is-admin). The insight security professionals should stress with the development team is that attackers constantly scour APIs for hidden fields as a means of gaining elevated privileges to then use for lateral movement and data theft. Security can help development remove or minimize the information exposed to improve API security.

Insight #4: Finding Undocumented/Shadow APIs

One of the common attack vectors in many data breaches is the undocumented doors into an enterprise network. The API discovery phase shines a bright light on these undocumented, hidden, or shadow APIs, as they are commonly referred to, that are being used by real clients but are not documented, tracked, or secured.

The API owner never meant to expose a particular resource or method in the specifications to clients, yet developers have implemented it as a hidden endpoint that can be used alongside other published endpoints. This result is a significant blind spot that could get exploited by attackers because neither the API owners nor the security team is aware of the APIs.

In the figure above, the API specification indicates that a GET method is publicly exposed for the /user/profiles/{profile-id} endpoint. But the discovery phase often finds API clients using a POST method to the same resource. This exposes internal values, editable by API clients but unknown to the API owner or security teams.

Attackers are constantly looking for backdoors like this to try and find endpoints that are open but were never designed to be so. The insight for security professionals to emphasize with development is that these hidden endpoints are eventually found by threat actors who will then try to use them as a backdoor for malicious purposes.

Insight #5: Suspicious or Unknown API Usage Needs to Be Blocked

The API discovery phase includes knowledge of how APIs are being used. Of particular importance are endpoints that handle PII or PCI information and often enable, user authentication, password resets, payments, billing, and other transactions involving sensitive information exchange. Security professionals are often surprised when we find:

• API usage from countries or from IP address ranges where they do not have any business operations
• Suspicious usage patterns such as password spraying on login endpoints
• Enumeration attempts to retrieve large amounts of information
• APIs without any built-in rate-limiting

While development and marketing may view increased or excessive traffic on an API as positive, security teams, armed with more detailed analysis on location and organization can share more insights that will justify the decision to block suspicious or unknown API traffic.

Summary

At this point, it is important for security professionals to be ready to take action to put the results of API discovery to work. They must put in policies to protect APIs from malicious, suspicious or anomalous usage. Relying on external inline systems like WAFs or firewalls is ineffective. The next logical question is about what forms of mitigation or blocking actions could be implemented by security teams to protect their APIs. We’ll explore that topic in a follow-up blog. In the meantime, check out this brief API Sentinel video: