Contact us
Request demo →
Contact us

The state of API security: global research comparison

by Cybersprint Analyst Report 10 Feb 2022

Previously, we reported on the security state of Swagger APIs all throughout Europe. After the EU region, we conducted the same investigation for North America and for the APAC region. This report will make comparisons between the API security levels in the three regions. What differences and similarities can we discern? IS API security a global issue?

The basics of APIs

An API (Application Programming Interface) is used by applications to communicate and interact between systems, access data, and much more. It defines the rules that programmers must follow to interact with a programming language or software tool. Basically, it makes sure you get the correct response on a request.

SwaggerAPI is part of REST APIs, and is used widely for this purpose as it is both machine-readable, as well as human-readable. In the developer’s own words, it “allows you to describe the structure of your APIs so that machines can read them.” This is used to build and share API documentation between IT specialists, and make different programs communicate with each other more effectively.

However, if someone were to intercept this request-response between programs, they could potentially misuse the data or alter the process. Cyber-criminals scan the internet for unsecured APIs on a daily basis. If not properly secured, this can lead to unauthorised access to internal data or customer information. What’s more, in some cases it allows tampering with data directly from an exposed API.

Our research

Our goal was to investigate the state of API security. We did this by finding exposed Swagger APIs and analyse those for misconfigurations and exposed confidential data. We chose Swagger as its tools are used extensively for creating and managing APIs.

We split the process into different parts:

  • Check for exposure of Swagger APIs using our Attack Surface Management platform in combination with bespoke scanning using Python and Shodan API;
  • Collect and process the data;
  • Analyse the data within confidentiality borders;
  • Generate and present the findings and statistics.

Results per region

As said, we conducted the same investigation method for three separate regions. Below is the total number of Swagger APIs we found per region. 

APIs found per region

The big differences can be explained by the distribution of hosting providers and large tech companies in the regions. Most APIs are hosted in the cloud, and the US has many more of these provides than the other two have.

Our platform generates an image of the number of APIs on a more detailed level throughout the three regions. Below is a distribution of the SwaggerAPIs for each region. We have made an interactive map of all SwaggerAPIs throughout Europe in this article. The static figures of the API distribution in the APAC, EU, and US regions are presented below.

Distribution APIs APAC

Distribution APIs EU.png (2)

Distribution APIs US.png

Next, we looked at the different hosting providers that the APIs were running on. For all regions, Amazon was the largest provider, with a higher percentage in the US and APAC. Google as a hosting provider was low compared to Amazon, and the rest was comprised of different smaller organisations offering similar services.


APIs by function

When detecting an API, the information within can tell you something about the specific use and function. We analysed the SSL certificates and host names of the Swagger APIs for more information of their purposes. Most of the APIs were unlabelled, as only about 10% of the APIs could be categorised for a specific function, as shown below.

APIs by function

API security

All security issues described below were found in all three regions. The issues occurred over a wide range of organisation types, sizes, and industries.

No authentication

We found many APIs without proper, or any authentication. The example below shows a payment API which is supposed to be protected, but most of the data is actually publicly accessible. It allowed us to send queries, resulting in the information such as email, home address, phone number, shipping address, and invoice data.

Payment API

Hard-coded API keys

A next example of lacking API security we found, was the existence of hardcoded API keys. These ‘forgotten’ keys often used to be there for a reason, as developers hardcoded them during the creation stages instead of sending/requesting the keys every time they had to work on the API. However, when these are then forgotten and not removed, they are available to anyone looking into the API code, as can be seen below. They provide full access to all functionality within the API system.

API catalog

Check code repositories every now and then
to see if you left any API keys in.

Data leak examples

With security issues on different levels for so many different organisations, a data leak is only waiting to happen. In our finding below, we highlight how entry to an API grants full access to their customer data. Theoretically, we were able to view and copy all identifiable customer data, edit the data, or add new customers to the system. This is an easy way for threat actors to carry out a fake invoice phishing scheme.

API data leak

Critical PII findings

Within the category of data leaks, we also found tens of thousands of records showing private information on people that made them personally identifiable. For example, we found an unsecured API which lead to the information of healthcare patients, including the types of treatments they were receiving and how much they had to pay for that.

Additionally, we found personal private information and copies of ID cards stored online, such as in the example below found in S3 buckets.



As a summary, the most common problems we found in SwaggerAPIs were:

  • Open APIs exposing private data
  • Hardcoded API keys
  • Missing authentication
  • Broken user authentication
  • API logic flaws
  • Outdated software

As mentioned in the introduction, Swagger API (Also known as OpenAPI) can be dedicated to different types of users. The issue starts when the API is not intended to be publicly accessible but actually is, making users data in danger of leaks and manipulation by threat actors. So what should you do to prevent such risks?

Our advice is to always develop and set up APIs with security in mind, and to continuously monitor for misconfigured APIs in your systems. 

  • Be aware of the choice and the possible consequences when using APIs in development/test/production environments. 
  • Always use HTTPS instead of HTTP. 
  • Have a (frequent) look at the OWASP API top 10 security. Use it as a reminder of the most common misconfigurations and weaknesses and how to improve your security. 
  • Though easier said than done, prevent hardcoding keys in the API, malfunctioning login mechanisms, observable data, etc. These use cases are illustrated above, and are common for a reason. 
  • Most importantly, it is best to have accurate and continuous insights into the APIs in your attack surface to see which could need a security. 

Additionally, many APIs have a very basic mistakes and don’t follow the Swagger specifications. Have a look at Swagger’s directions to solve such mistakes.


Interested to see what Attack Surface Management can do to prevent API risks for your organisation? Click below to see our API Security data sheet. 

View Data Sheet API Security

Disinformation: a certainty in uncertain times

Since the beginning of the internet, we have seen a near, if not an exponential, surge of information sharing amongst users in cyberspace. Not long after, we saw how the emergence of social media ushered an access to public online platforms where other internet users worldwide could share, discuss, promote, and consume information, whether by deliberate choice or not.

read more

Threat Report: Remote vulnerability in Confluence, fixes available

On 2 June, 2022 a critical vulnerability was identified in Atlassian Confluence (CVE-2022-26134). The vulnerability in question relates to active exploitation of unauthenticated remote code execution in Confluence Data Center and Server; meaning that the vulnerability could lead to code being executed remotely.  

read more

Looking back on the 2021 vulnerability: Log4shell

In December 2021 a critical vulnerability surfaced named Log4shell within Log4j, a widely used logging tool for java applications. Log4j is used globally by computers running online services, which meant it impacted a multitude of people, organisations, and government organisations. Since then, multiple fixes have been implemented in the hope to avoid such an outbreak in the future.

read more

Do you have a question?

Our experts have the answers

Contact us