The shift from HTML-based websites to REST-based programming interfaces is progressing rapidly. OWASP is thus publishing a new and specialised top 10 list for API security. Dedicated security products such as web application firewalls, API gateways with corresponding extensions and identity and access management systems can make a significant contribution to securing APIs, but developers must also be committed and do their part to ensure the optimal protection of the company's resources.

The importance of HTML-based websites and portals has been decreasing for several years. There are numerous different reasons for this. The growing use of smartphones and tablets is an important aspect of this because it is more efficient and cost-effective for applications to already be installed on the device, meaning only the data has to be loaded via the Internet. IoT devices and wearables are usually too small to display and operate websites, but data exchange via the Internet is a key element for their use. The continuous development of web browsers now allows developers to implement an optimal user experience which automatically adapts to the framework conditions of the device used.  One thing these developments have in common is the fact that the data is obtained from the Internet and that the REST interfaces required for this are increasingly becoming key building blocks of the Internet architecture.

APIs in the service of the user experience

The increasing significance of REST interfaces is due to the fact that the architecture paradigms of the application development had to adapt to user requirements. Mobile first leads to modern applications being developed either directly as native mobile applications or as single page applications (SPA) directly in the browser. These applications can use a variety of APIs from very different sources and only combine them in the client. Software developers are supported by large and functionally extensive ecosystems: Android Studio, Xcode, React or Angular to name just a few. This results in applications which enable a user experience which is very close to that of rich clients without having to accept their disadvantages.

From the point of view of the API provider, it is a matter of exposing a combination of business logic and data in such a way that the applications can use them efficiently and securely. This means that each API provider must ensure the security of the offered API. It is not possible to delegate this responsibility to upstream applications or portals because APIs must be exposed directly on the Internet.

The evolution of the REST interfaces is based on the same HTTP protocol that has already been highly successful for HTML-based websites. It is therefore not surprising that many potential attacks are very similar to attacks on traditional websites or portals. According to a study by Gartner on API Security [1], by 2021, the largest attack point in 90% of web applications will arise through exposed APIs. By 2022, API abuse will become the primary vector of attack and lead to global data breaches. However, there are already enough reports of incidents that can be traced back to poorly secured APIs.


System Owner


Effect of Data Leaks


US Postal Services Hack


All user accounts including address, telephone number and e-mail

Brazil Fed of Indus - ElasticSearch API exposed


34.8 million user accounts

Urban Massage - ElasticSearch API exposed


309,000 user accounts including transaction data

SKY Brasil - ElasticSearch API exposed


32 million user accounts, 492 GB of API data

Atrium Health - ElasticSearch API exposed


2 million patients including social insurance number, date of birth. No medical data 12438109/personal-data-of-more-than-2m-patients -compromised-in-atrium-health-data-breach



44.3 million user accounts

Smart Watches PWNED


Control over hundreds of smart watches

JustDial Leak


100 million user accounts including mobile phone numbers

GateHub Cryptocurrency Wallet Hack


Crypto-currency stolen from XRP Ledger wallets

Venmo transactions Leaked


7 million transactions

Suprema: "Biostar 2" (Biometrie DB)


27.8 million user profiles, profile data, usernames, passwords, facial images, fingerprints.

Adobe Creative Cloud - ElasticSearch API exposed


7.5 million user accounts

OnePlus räumt Datenleck ein


User accounts with address, telephone number and e-mail.

[1] “API Security: What You Need to Do to Protect Your APIs”, Mark O'Neill, Dionisio Zumerle, Jeremy D'Hoinne, Gartner, 28.8.2019

Data security and data protection

In the healthcare sector, the quick and reliable exchange of structured medical data is a requirement that doctors and, increasingly, patients are demanding. However, the reality shows that the exchange often still consists of scanned documents or PDFs being transmitted via fax and e-mail. However, there has been movement into healthcare in the last two years because the big IT providers: Apple, Google, Microsoft and Amazon are actively investing in the topic "Personal Health Record" and all rely on the same standard: FHIR.

FHIR describes a REST interface with functions and data, and thus enables the exchange of structured medical data. The major providers position FHIR as a key technology for achieving a data exchange between practitioners and patients. FHIR also fulfils all the requirements to become an exchange standard in the entire healthcare sector.

The sector of ​​financial service providers is one step further. In the EU, a law was passed with PSD2 that forces all banks to offer REST interfaces on the Internet, which can be used to request account information and to record payment transactions. This has led to the emergence of several standards based on the legal bill which specify the REST interfaces required for implementation in detail. The impact of European legislation has been enormous. In the document from PwC you can see that this development is having a global impact and recommendations or laws are also being developed in the USA and Asia.

REST interfaces with an increased level of IT security are thus catching on in two sectors. FHIR involves health data, whereby the GDPR unequivocally stipulates that this is particularly sensitive data requiring protection, and PSD2 relates to applications in the financial industry where customers have clear expectations regarding the security of their assets and where any possible reputational risk is taken very seriously.

OWASP Top Ten and OWASP API Security 

When it comes to discussing risks and threats to applications on the Internet, all paths lead to the OWASP Top 10. The OWASP is a non-profit organisation and the Top 10 is probably their best-known project. Since 2003, the Top 10 project has been releasing a prioritised list of vulnerabilities/risks and possible countermeasures based on the data from hundreds of organisations around the globe. 

OWASP’s API security project has also been publishing a Top 10 list since December 2019. While API security was not missing from the well-known Top 10 list, here OWASP takes into account the fact that the importance of interfaces and particularly REST interfaces has significantly increased, justifying an independent catalogue of threats and measures.

Overview of the top ten API vulnerabilities

The following table shows the full list of API vulnerabilities according to OWASP:





Broken Object Level Authorisation 

APIs tend to expose end points which process object identifiers, creating a larger area of attack for access controls. Authorisation checks at the object level should be taken into account for every function accessing a data source via user input.


Broken Authentication 

Authentication mechanisms are often implemented incorrectly, so attackers can compromise authentication tokens or exploit implementation errors in order to take over the identity of another user temporarily or permanently. If the system’s ability to identify the client/user is impaired, API security is impaired as a whole. 


Excessive Data Exposure 

Considering the very general use of APIs, developers tend to disclose all attributes of objects regardless of individual protection requirements. They rely on clients to filter data before it is shown to the user.


Lack of Resources & Rate Limiting 

APIs often contain no restrictions relating to the size or number of resources which can be requested by the client or user. This can affect not only the performance of the API server, leading to denial of service (DoS), but can also keep the door open to authentication faults such as brute force.


Broken Function Level Authorisation 

Complex access control guidelines with different hierarchies, groups and roles as well as an unclear division between administrative and regular functions tend to lead to authorisation errors. Exploiting these problems gives attackers access to the resources and/or management functions of other users.


Mass Assignment 

Linking data provided by the customer (e.g. JSON) to data models without suitable filtering of the properties based on a whitelist generally leads to mass assignment. Guessing object properties, exploring other API endpoints, reading documentation or providing additional object properties in request payloads allows attackers to change object properties that they should not change.


Security Misconfiguration 

Errors in security configuration are usually the result of insecure standard configurations, incomplete or ad-hoc configurations, open cloud storage, incorrectly configured HTTP headers, unnecessary HTTP methods, permissive cross-origin resource sharing (CORS) and detailed error messages with sensitive information.



Injection errors such as SQL, NoSQL, command injection, etc. arise when untrustworthy data is sent to an interpreter as part of a command or a request. The malicious data of the attacker could cause interpreters to execute unintended commands or to access data without the respective authorisation.


Improper Assets Management 

APIs tend to publish more end points than traditional web applications, which makes it particularly important to have correct and updated documentation. Correct inventory of hosts and available API versions also plays a key role in reducing problems such as outdated API versions and exposed debug end points.


Insufficient Logging & Monitoring 

Insufficient logging and monitoring, coupled with a lack of or ineffective integration into the risk prevention system, enable attackers to intensify their attacks, nest themselves more deeply and expand their attacks from other systems. All with the aim of manipulating, extracting or destroying data. Most studies show that the time required to detect a breach is over 200 days, and this is usually achieved by external parties rather than internal processes or monitoring.

OWASP API Security 2019 vs. Top Ten 2017

If you compare the new top ten list for API security to the current list for web applications from 2017 (A1-A10), you’ll quickly find that certain vulnerabilities are present in both lists in a comparable form and with similar weighting:

  • Broken Authentication: API2 is identical to A2
  • Excessive Data Exposure: API3 is similar to A3
  • Security Misconfiguration: API7 is comparable to A6
  • Injection: API8 is identical but differently prioritised to A1
  • Insufficient Logging & Monitoring: API10 is identical to A10

This is hardly surprising since the similarities between traditional websites or portals and applications using REST interfaces are huge. The applications follow the same purpose and the technologies used are closely related. The applications also need to solve the same problems, for example the authentication of users, the authorisation of data access, the persistence of data, the deployment in the cloud or data centre, writing logs or embedding in monitoring systems. 

The differences, rather than the big similarities, are the exciting part. The topic of injection is featured on both lists in terms of content, but the assessment of the priority is quite different. A possible explanation is that the tools used for REST are applied extensively and that they already solve numerous problems in the area of input data validation without further action by the developer. Such tools were far less sophisticated when traditional web applications first arose and the risk for traditional web applications can thus still be assessed to a greater extent today. However, the fact that injection must generally be prevented in the API itself since an API cannot rely on the protection of "well-disposed" clients is an argument against this explanation.

One threat which does not seem to apply to APIs is the XML External Entities (XXE) vulnerability. It stands to reason that the authors of the API security risks are primarily focusing on REST interfaces, because SOAP web services are virtually unused in the area of mobile applications or in browser SPAs. Cross-site scripting (XSS) is also missing from the API security risks list. While it is correct that XSS is primarily a browser problem and APIs themselves do not interpret JavaScript, APIs could transmit JavaScript and thus be involved in XSS. The authors presumably assumed that the input validation of the API8 also prevents JSP injection and that XSS is therefore unnecessary as an independent risk. 


Measures to protect APIs

Development of a security infrastructure

The use of specialised security components to protect exposed interfaces is now considered best practice. This assertion applies regardless of whether the specialised security components act at the periphery of the company network, whether every individual interface is protected by its own security components as a zero trust architecture, or whether a hybrid approach comes into play.

There is a wide selection of products available for the implementation, but the following functions must always be covered: 

Airlock combines these 3 components in one centralized Secure Access Hub.

Depending on the manufacturer, there may be deviations in how the architecture is implemented in detail as the number of components and the distribution of functions on the components can be implemented differently. However, this is not decisive for reducing the risks of the OWASP API security. The key element is implementing and correctly configuring the different functions in the selected product (API7)

The area of attack can thus be significantly limited as the only APIs that are truly exposed are those which should be externally accessible (API9). This prevents the unnecessary exposure of interfaces which are only intended for internal use.

If an OpenAPI specification is available, then the API gateway can limit access to the functions explicitly specified for release (API9) and carry out a formal input validation of the transmitted parameters (API8).

Rate limits can be implemented in the API gateway (API4) without the actual business logic or data persistence being loaded with excess requests. In many products, the policies are implemented in such a way that even complex business models can be supported which impose different limits depending on the user.

Identity and access management systems ensure that users are appropriately authenticated (API2). Modern IAM systems support standards with OAuth, OpenID Connect or SAML and thus propagate the verified identity of the user to the applications and APIs (API5). IAM systems enable the implementation of single sign-on over several applications and often also offer user self-services functions. 

Both systems, API gateway and IAM, generate technical as well as functional log output which is ideally collected and analysed in a SIEM system (API10). 


Responsibilities for developers

Attentive readers will have noticed that not all API risks can be addressed with upstream security components as business rules are only known in the interface's business logic and can therefore only be enforced there. The question of whether a certain user can really access a specific business object can only be answered in the business logic of the application (API1) but also, in connection with API3 and API6, developers are obliged to design their APIs in such a way that only the necessary information is exposed and only what should be allowed is in fact allowed. 

As a software developer, however, one should be aware that software is only secure if it is taken into account during development that the software can be used without any upstream security components. "Security by design" is a requirement that should be followed particularly when developing APIs.


The list of OWASP API security risks is the result of the increasing importance of REST interfaces and it is the logically consistent continuation of the OWASP Top 10 list. However, increasing importance also leads to increasing threats as APIs are already being attacked and will be even more so in the future. Suitable security components (Secure Access Hub: web application firewall, API gateway, identity and access management systems) can help reduce the risks, but developers are also obliged to ensure that business logic and data are handled securely.

Airlock's Secure Access Hub offers secure protection against the OWASP API Security Risks and the OWASP Top 10.



Blognews directly to your inbox

The Airlock Newsletter informs you continuously about new blog articles.

Subscribe blognews

Comments 0

More interesting articles

5 security challenges in an open banking ecosystem

5 security challenges in an open banking ecosystem

OWASP launches new top ten list for APIs

OWASP launches new top ten list for APIs

Airlock Secure Access Hub - more than the sum of its parts

Airlock Secure Access Hub - more than the sum of its parts

Information for you

-Our whitepapers-

Zero Trust is a journey

The digital transformation of the world continues to progress, and it is profoundly affecting private life and job profiles in a manner that was hard to imagine just a few years ago.

This whitepaper covers the effects of continuous digitization and its implications.

Request free of charge

Toward DevSecOps

In this whitepaper, you will learn the most important insights into how you can successfully and efficiently implement DevSecOps, which security components are required for this, and what benefits a microgateway architecture brings.

Request free of charge

Airlock 2FA - Strong Authentication. Easy.

The two-factor authentication in the area of IT security offers double the security.

Find out more about strong authentication and the possibilities that Airlock offers in our whitepaper.

Request free of charge

Further whitepapers

We provide whitepapers on these and other topics free of charge:

  • successful IAM projects
  • Compliance
  • Data protection (GDPR)
  • Introduction of PSD2
  • PCI DSS requirements
Request free of charge