One of the most difficult parts of adopting a set of APIs is comparing them. Developers often compare different strategies and tools, and finding a good balance between security, reliability, and performance can be quite difficult. APIRank.dev is a potential solution to this problem.

By scanning thousands of APIs and applying a ranking system across security, performance, reliability, and design, popularity, APIRank.dev provides a relatively comprehensive ranked list of APIs on the open web. It’s an ongoing report from Escape.tech, a company that focuses on GraphQL endpoint validation and security testing. With that in mind, let’s look at what the service does to see what niche it fills.

The State of Public APIs in 2023

APIrank.dev has scanned 7,420 endpoints over 83,245 requests at the time of writing, generating a view of APIs across OpenAPI 2.0 and 3.0+ specifications on the open web. From this scanning, a report was developed that delivered some interesting results.

Firstly, the percentage of specifications with a license (such as Creative Commons or MIT) made up 38% of surveyed APIs, and the percentage of specifications without composed 62%. Additionally, 56% of specifications had a contract, while 44% did not. Finally, 33% of specifications had a term of service, while 67% did not.

So far, so good. Where things get really interesting is in the security section. APIRank.dev compared APIs against the OWASP top ten list of API vulnerabilities to expose security issues. The results were —frankly — staggering. Over 90% of public APIs tested had a significant OWASP vulnerability. During subsequent testing, sensitive data, including emails, JSON web tokens, passwords, generic keys, and even cryptographic hashes, were found in error messages across the open web.

APIRank.dev ranks thousands of APIs to determine the ones with the highest reliability and security.

Performance was a better picture overall. The majority of tested APIs fell within a 400ms to 700ms range, with far slower and far faster services standing out as significant deviations. Reliability was perhaps the best-performing section of the test, with only 6% of tested APIs generating straight 500 errors.

Onto the most nebulous of the ranks in this project — design. This aspect was relatively good across the board. About 90% of all documentation had a description, and 60% of routes had human-readable comments. However, examples were far less common, with 90% of surveyed documentation having zero provided examples.

The Takeaway: What Makes a Secure API?

Based on the output of this project, we can start looking at some common vulnerabilities that API providers should test against to ensure a secure API. Below, we’ll look at the most common OWASP vulnerabilities found on APIRank.dev and suggest methods to mitigate each risk.

A01:2021 — Broken Access Control

API access control is, in theory, quite simple — access to elements of an API and its underlying data is restricted based on a set of permissions. A set of permissions for a user might be different from a set of permissions for an administrator, for instance, and adherence to this set of permissions can help ensure that only those who need to access the data actually can.

Unfortunately, this is also a widespread area of insecurity. Violating the principle of least privilege, allowing tampering with URL parameters, and access to paginated URIs represented by other user data is all quite common, according to this report.

To mitigate this, providers should first deny by default and depend on the principle of least privilege. From here, access should be restricted to a set of pre-determined and well-worn pathways that reduce Cross-Origin Resource Sharing and refuse unsourced navigation. A set of different approaches can be taken to ensure this is made more secure, but even a basic effort can improve security by leaps and bounds.

A07:2021 — Identification and Authentication Failures

This is perhaps the most common issue in the minds of most users. Things such as automated attacks against users, credential stuffing, brute forcing, and permitting weak or well-known passwords fall into this category. Additional issues around plaintext password storage, missing two-factor authentication, and session reply fall into this category, though credential stuffing is far more common.

Thankfully, as common as this is, it’s pretty easy to fix. Ensuring two-factor or multi-factor authentication using secure systems is a big first step, assuming you can secure the secret key. Removing default credentials, particularly for admin users, and enforcing higher levels of authentication for such users is another great step forward. Beyond this, basic security standards, rotation politics, and brute force prevention approaches can mitigate this particular concern significantly.

A09:2021 — Security Logging and Monitoring Failures

Security logging and monitoring is another relatively common error, but this area is particularly insidious as it’s hard to detect unless you know there is a problem. Logging and monitoring are precisely what it says on the tin — logging interactions and monitoring for behavior divergent from expectations.

The problem is that most issues in this realm often result in everything looking like it’s functioning correctly. If someone has broken into a system, chances are that, if they’re good at what they do, they will remove evidence of intrusion. If your logging system never really worked in the first place, you might not know until you discover the logs aren’t there (or aren’t complete).

OWASP notes the following as potential issues within this realm:

• Auditable events, such as logins, failed logins, and high-value transactions, are not logged.
• Warnings and errors generate no, inadequate, or unclear log messages.
• Logs of applications and APIs are not monitored for suspicious activity.
• Logs are only stored locally.
• Appropriate alerting thresholds and response escalation processes are not in place or effective.
• Penetration testing and scans by dynamic application security testing (DAST) tools (such as OWASP ZAP) do not trigger alerts.
• The application cannot detect, escalate, or alert for active attacks in real-time or near real-time.

Preventing these issues comes down to properly vetting and deploying systems and then auditing them regularly. You can only trust a system that has been tested, so routine auditing and testing must ensure everything is doing what it should be.

A05:2021 — Security Misconfiguration

This category is a bit of a catchall in that it represents a wide range of misconfigurations. As such, it’s hard to pin it down to one specific problem. That being said, the presence of any particular problem within this category suggests the presence of other issues.

The key here is understanding the concept of Common Weakness Enumeration, which is a specific weakness that is detectable and comes with a specific fix. Issues in this realm might include things like sample applications that are packaged with the deployable materials, allowing for internal privilege escalation or sidechain attacks on internal data stores.

This can often come from reusing vulnerable or out-of-date components, especially when they have obsolesced and have been replaced with more secure variants or paradigms. A more complete guide to this type of issue can be found courtesy of OWASP.

Data Security and Privacy

Unfortunately, general failures of data security and privacy are common in the survey data. While many of these issues can arise from the vulnerabilities mentioned above, as a general category, this bears its own discussion.

Users are the lifeblood of any application, and this is especially true of APIs. Unfortunately, developers often think of users in the abstract, forgetting that these are real people using real systems, and their data is as important to them as the developer’s own data would be to themselves. Accordingly, failures in properly safeguarding this data come from a misevaluation and inadequate forethought.

Data security and privacy is a fundamental human right in many places of the world (and, arguably, should be everywhere, regardless of current legislation). Accordingly, developers should plug any potential security lapse within these categories if they are trying to make a truly secure (and trustworthy) API.

Conclusion on APIRank.dev Findings

APIrank.dev is a helpful benchmarking of many public APIs. But to be fair, there are indeed issues with duplicate APIs, such as Spotify claiming high ranks, and yes, not all APIs are represented on this list.

Nevertheless, APIrank.dev is an invaluable tool as it allows comparison in an apples-to-apples way across very different systems. This helps developers find new solutions and raises questions about security and common vulnerabilities to the forefront in a way that is not often done effectively. For this, APIrank.dev is a great tool, and these vulnerabilities are a fantastic jumping-off point for finding and mitigating common issues.

What do you think of APIrank.dev? What kind of tooling around security comparisons would you like to see in the future? Let us know in the section below!