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 | Date | Effect of Data Leaks | Citation |
US Postal Services Hack | 21.11.2018 | All user accounts including address, telephone number and e-mail | https://krebsonsecurity.com/2018/11/usps-site-exposed-data-on-60-million-users/ |
Brazil Fed of Indus - ElasticSearch API exposed | 23.11.2018 | 34.8 million user accounts | https://www.zdnet.com/article/brazils-largest-professional-association-suffers-massive-data-leak/ |
Urban Massage - ElasticSearch API exposed | 27.11.2018 | 309,000 user accounts including transaction data | https://techcrunch.com/2018/11/27/urban-massage-data-exposed-customers-creepy-clients/ |
SKY Brasil - ElasticSearch API exposed | 29.11.2018 | 32 million user accounts, 492 GB of API data | https://www.zdnet.com/article/sky-brasil-exposes-data-of-32-million-subscribers/ |
Atrium Health - ElasticSearch API exposed | 29.11.2018 | 2 million patients including social insurance number, date of birth. No medical data | |
Data&Leads | 29.11.2018 | 44.3 million user accounts | https://www.bankinfosecurity.com/blogs/data-leads-site-disappears-after-data-exposure-alert-p-2687 |
Smart Watches PWNED | 2.4.2019 | Control over hundreds of smart watches | |
JustDial Leak | 17.4.2019 | 100 million user accounts including mobile phone numbers | https://thehackernews.com/2019/04/justdial-hacked-data-breach.html |
GateHub Cryptocurrency Wallet Hack | 6.6.2019 | Crypto-currency stolen from XRP Ledger wallets | |
Venmo transactions Leaked | 16.6.2019 | 7 million transactions | https://techcrunch.com/2019/06/16/millions-venmo-transactions-scraped/ |
Suprema: "Biostar 2" (Biometrie DB) |
| 27.8 million user profiles, profile data, usernames, passwords, facial images, fingerprints. | |
Adobe Creative Cloud - ElasticSearch API exposed | 26.10.2019 | 7.5 million user accounts | |
OnePlus räumt Datenleck ein | 23.11.2019 | 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:
Number | Title | Description |
API1 | 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. |
API2 | 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. |
API3 | 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. |
API4 | 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. |
API5 | 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. |
API6 | 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. |
API7 | 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. |
API8 | Injection | 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. |
API9 | 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. |
API10 | 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:
- Web application firewall for the protection of websites and portals
- API gateway for the protection of REST interfaces
- Identity and access management for access control to websites, portals and interfaces
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.
Summary
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.
![[Translate to Englisch:] Tablet](/fileadmin/_processed_/f/3/csm_EGN_Airlock-Blog_2880_Newsletter_01_9738ee447c.webp)
Blognews directly to your inbox
The Airlock Newsletter informs you continuously about new blog articles.