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.
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.
.jpg?width=624&name=Distribution%20APIs%20EU.png%20(2).jpg)
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.
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.
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.
TIP
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.
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.
Conclusion
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.
