Contact us
Request demo →
Contact us

Swagger API: Discovery of API data and security flaws

by Cybersprint Analyst Report 23 Dec 2020

APIs (Application Programming Interface) are used by applications to communicate and interact between systems, access data, and much more. It makes sure you get the correct response on a request. However, if someone were to intercept this request-response, 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.

This technical article focuses on mapping and discovering Swagger APIs throughout the EU. We will present how we discovered those APIs and checked for misconfigured examples. We will illustrate each step using screenshots, present the results, and provide defensive recommendations.

Research conducted by Soufian El Yadmani, Security Analyst at Cybersprint

The interactive map below shows how many Swagger APIs we found, and in which region. You can click, drag and zoom to see how many Swagger APIs were found in your area.




Key findings

We discovered 13,041 Swagger APIs in 28 countries throughout Europe. Further analyses revealed that many are not properly secured, revealing hardcoded keys and user/customer information, malfunctioning login security, no use of HTTPS, and more.

This could lead to the manipulation and leaks of sensitive information such as names, physical addresses, phone numbers, credit card details, and invoice specifics. 



Before we dive into the research, let’s start with a few definitions.

Types of API consumers

There are three types of consumers:

  1. Internal or Private consumers
    The internal consumer is the part of same organisation that is the provider of the API.
  2. Partner
    This user has a trusted relationship with the organisation that is creating and exposing the API.
  3. Public or External consumers
    The public consumer is outside of the organisation that is creating the API or that owns the API.


   / Representational state transfer (REST) APIs allow access and manipulation of web resources through predefined, stateless operations. 
   / Mainly based on HTTP protocol (GET, POST, PUT, DELETE, HEAD)
   / Supports TLS encryption
   / Uses JSON format to facilitate data transfer over Web browsers
   / Flexible but does not implement native security measures

Swagger API

Swagger specification (also known as OpenAPI) is an API description format for REST APIs. A Swagger file describes the entire API, including available endpoints, operations on each endpoint, operation parameters input, and output for each operation. 

The Research

This article focuses on mapping and discovering Swagger APIs throughout 28 countries in the EU.




















Czech Republic







the Netherlands

United Kingdom




In total, we found 13,041 records. We will present how we discovered those APIs, check for misconfigurations, present statistics, and give recommendations on how to properly secure APIs. The table below represents the countries included in this research. 


Our main goal was to find exposed Swagger APIs in the European Union and analyse them for misconfigurations and exposed confidential data. Naturally, upholding the confidentiality of (exposed) data is vital in this research. We did not dig deeper into the data or looked into the contents or systems of the APIs.

We split the process into smaller parts: 

  1. Check for exposure of Swagger APIs;
  2. Collect and process data;
  3. Analyse the data;
  4. Correlate and present the findings and statistics.

These are the technologies and the data sources used in this research, as also presented in figure 2.

  1. Data gathering using Python and Shodan API;
  2. Storing the data in Elasticsearch;
  3. Generate graphs and statistics using Kibana.

Fig 2. Process of gathering and analysing data


Now, let’s dive deeper into the details of the processes.


The data was gathered via Shodan through its API, and by using Python. Shodan is a powerful internet search engine and is used by researchers and threat actors alike to find unsecured devices and exposed databases. The queries we used searched for the word “Swagger” in HTML content of the site, combined with the 28 EU countries. It is a strong indicator that the website runs Swagger API.

Fig 3. Shodan queries used in the research

We gathered all results of the previous queries using python and Shodan API. For this research we were not interested in all fields, so we only covered the following:

Fig 4. Example of input


We used Elasticsearch to collect, process and store the data. Each result was stored according to the format in figure 4 into an index we called Swagger_research. Figure 5 represents an example of results from Shodan stored in Elasticsearch. 

Fig 5. Example of stored data in Elasticsearch


As stated above, we found a total of 13,041 exposed swagger APIs. We discovered many examples of misconfigured Swagger APIs, such as APIs with hardcoded keys, internal data regarding employees, clients, invoice data, factures exposed to the public as well as some examples in which access via API key and login was broken.

In this section, we will list some of these examples and explain how they expose confidential data. The three main API security examples below present only a few of the many misconfigurations we discovered. As mentioned in the introduction, Swagger APIs can sometimes be public on purpose, that’s why we focused on examples where the presented data shouldn’t be public, or is misconfigured in such a way that it could lead to a data leak.

Hardcoded keys

The first example is an instance where the API keys were hardcoded in the instance itself. These keys were probably coded there as an example but they are actually valid and anyone can use them to interact with the API, as shown in figure 6.

Fig 6. Hardcoded API keys in Swagger

The apiKey and all other fields have hardcoded valid values that can be used to interact with the API. That is not the only issue in this particular example; the issue is that you can use the hardcoded values to initiate and update payments, as well as getting information of payments which gives you access to people’s data - data that is not supposed to be public.

No security

This second example is one of many examples where the Swagger API didn’t use any kind of protection and was probably not yet supposed to be public, mainly because of the data it exposes. This is shown in figure 7.

Fig 7. Data leak through Swagger API

Next, requesting the operation Customer gives you every detail you want to know about the customer, including the email address, phone number, shipping address, and invoice. The API doesn’t only give you access to the data, but you can actually manipulate it through the API. We decided not to show an example of the output, as this might give away too much data. 

The unprotected API gives you access to basically every possible operation on the customers, payments, refund, and subscription. A threat actor can easily manipulate the data using these operations. 

Broken authentication

This third API example is meant to be protected with authentication using an email address and password. As shown in figure 8, the user must authenticate to generate an access token. 

Fig 8. Swagger API protected with authentication

Unfortunately, this authentication doesn’t work as intended as it is incorrectly implemented. This means that anyone can directly use the API without login. This example can be categorised as a ‘Broken User Authentication’, also listed in the OWASP API TOP 10.

The next figure is an example of usage of this API without requiring login or any kind of user information. We can request and manipulate all data using this API, as shown in figure 9, we can request Administrators data such as id, full name, email, phone number and role.

Fig 9. Broken authentication in a Swagger API


In this section, we present the correlated findings and data. We used Kibana to visualise the data index processed in our Elasticsearch instance, as shown in figure 10. 

Fig 10. Data index in Kibana

Next, we categorised the number of Swagger APIs found for each of the 28 countries. The results are shown in figure 11. By far, most of the discovered APIs are found in only five different countries (Ireland, Germany, the Netherlands, the United Kingdom, and France). One possible explanation is because of the geographical position of these countries. They are home to many multinationals within the EU with connections and operations in North and South America. Consequently, some of the most popular cloud service providers are located in these countries.

Fig 11. Exposed Swagger APIs per country in the research


Correlating cloud connections

This lead us to a secondary research question. As most swagger APIs are found in countries with the most-used cloud service providers, we wanted to see if there was a correlation between the two. We used the hostnames of the cloud providers in Shodan output, giving an idea which cloud providers are used to host Swagger APIs.

Fig 12. Cloud providers hosting Swagger APIs

As shown in figure 12, more than half of the discovered Swagger APIs have Amazon as a host provider. This is in line with the high number of Amazon instances in countries such as Ireland, Germany, the Netherlands, the UK, and France, as illustrated by the AWS Global Infrastructure Map. Though we could not find a direct link from this data without compromising information security, it can be said that a third-party provider, Amazon in this case, hosting a large number of APIs increases the importance of control on supply chain security. 

The Null in the graph represents API records with an empty hostname field, Others represents a broad collection of smaller cloud providers. 

API lifecycle

The second record we wanted to check was the assets using HTTPS. This, using the certificate information can determine in what stage of development those APIs are, as the developers usually use the Common Name field to identify the stage they are working on, e.g. dev, staging, test, prod. 

More than half of the Swagger APIs discovered did not even use HTTPS. Of the 13,041 instances, 7,479 Swagger APIs were used over HTTP, and 5,562 over HTTPS. A graph of the different SSL Common Names in the APIs is shown in figure 13.

Fig 13. Different API keywords in SSL Common Name


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. Now that we have illustrated the most common misconfigurations , we will discuss some of the measures that can be taken to protect Swagger APIs.

Swagger has many ways to secure the API. OpenAPI defines this as the “security scheme”. The following are the security schemes that can be used:

  • HTTP Authentication - can be done using Basic Authentication, Bearers and other HTTP Schemes;
  • API key - which is basically a token the user should provide to make use of the API;
  • OAuth 2 - a protocol that can be used to limit API client access to user data on a web server;
  • OpenID Connect (OIDC) - which is a simple identity layer on top of OAuth 2.0 protocol to define sign-in-flow that enables a client application to authenticate a user.

We cannot recommend one scheme over another, as this depends highly on the individual setup and purpose of the API. More information about Swagger API security schemes can be found here.

During this research we tried to cover some of the exposed Swagger API in the EU. During the research, we came across many examples where client data is publicly exposed and can be easily manipulated by attackers. API Security is still a big challenge for many organisations and can have grave consequences when abused. An attacker can get direct access to customers’ data and even manipulate it, compromising data confidentiality and integrity.


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 


Are you curious about the API security in your attack surface? Contact us for more information. 

Contact us

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