APIs (Application Programming Interfaces) allow companies to modularize functions and easily provide them to customers and third-parties. Current statistics show the increasing usage of APIs is accompanied by increasing security concerns. In 2021 the API traffic increased by 321%, whereas attacks on them increased by 681% compared to 2020, based on the latest report by Salt labs. 95% of all organizations had an API cyber security incident in the past 12 months [1] and the Google searches for the topic “Web API Security” increased by 400% since 2016 [2]. Current research by Imperva indicates that APIs account for 4,1% to 7,5% of all yearly cybersecurity attacks incidents and result in damages of 41 to 75 billion dollars.
Top 10 Most Critical Risks for APIs
APIs can provide critical functionalities and information; hence their security is a crucial aspect. To secure APIs and to diminish the risk of a cyber security incident, it is important to test for the most critical risks and mitigate them. The OWASP API Security Top 10 is a ranking of the 10 most critical security risks for APIs. It is established by the Open Worldwide Application Security Project (OWASP) which is a non-profit organization that is highly valued by cyber security experts worldwide. The top 10 risks are described in the following table:
| Rank | Title | Description |
|---|---|---|
| 1 | Broken Object Level Authorization | The API doesn’t check whether a user is authorized to access a specific resource (usually referenced by an ID). Thus, an attacker can replace their ID to access a resource of another user. A more complex example is the usage of OAuth 2.0. While OAuth is the industry standard for authorization, a weak implementation can enable an attacker to steal or manipulate authorization tokens. Using these tokens they can access foreign resources. For high-security APIs, such as in the banking sector, it may also be necessary to use the financial-grade API (FAPI), which defines (more complex) high security profiles for OAuth. Learn more about FAPI in our German blog series. |
| 2 | Broken User Authentication | The APIs authentication isn’t sufficiently secured. This includes various examples, such as not validating the authenticity of tokens or using weak signatures. |
| 3 | Excessive Data Exposure | The API is returning more data than necessary. This excessive data might be confidential or utilized by an attacker for further attacks. |
| 4 | Lack of Resources & Rate Limiting | The API is not protected against an unusual amount of traffic and doesn’t limitate a user’s API calls or parameters can be modified to cause performance issues. Thus, an attacker can flood the API with arbitrary calls in order to overload it, leading to Denial of Service (DoS). |
| 5 | Broken Function Level Authorization | The API isn’t sufficiently secured against unauthorized calls. For example, an attacker can invoke admin APIs with a non-privileged user account. |
| 6 | Mass Assignment | The API allows it to store more data than intended. An attacker might know or guess additional object properties and add them to the API call; thus manipulating data which wasn’t supposed to be writable by the user. |
| 7 | Security Misconfiguration | The API’s server is configured in an insecure manner. There are many ways to misconfigure a server. One example is a misconfigured web cache which can lead to a vulnerability called “web cache poisoning”. We wrote a detailed blog post about this vulnerability and created a CLI tool called Web Cache Vulnerability Scanner to scan for this vulnerability. |
| 8 | Injection | An attacker is able to include data in the API calls, which is executed by the backend. This can be, among others, SQL queries, XML data, or OS commands. |
| 9 | Improper Assets Management | An attacker is able to call non-productive or old versions of APIs. These APIs often contain known vulnerabilities, which don’t get fixed, because the APIs weren’t meant to be used publicly. Non-productive APIs might also provide debugging information and omit sufficient security checks. |
| 10 | Insufficient Logging & Monitoring | Attacks aren’t noticed in a reasonable timeframe or not noticed at all because there’s a lack of proper logging and monitoring of the API calls. |
Security in the API Lifecycle
It is important to consider cyber security in all phases of the API lifecycle: design, implementation and management.
During the design phase it is crucial to keep the most critical risks in mind and answer questions like:
- Which APIs must have authentication?
- How do we securely implement authentication?
- What are the pitfalls while implementing OAuth? (Learn more in our in-depth training.)
- How do we validate user input in order to prevent injections?
This helps to minimize the security risks in the final API later.
During the implementation phase it is important to conduct not only function tests but also security tests. During a survey in 2021 29.5% of all developers reported that they do functional testing, however only 4.3% do security testing; this is an alarming low number. Automated security tests provide, once set up, an efficient way to test for security risks. However, they can only ensure a basic security level; thus manual testing, such as thorough penetration tests, is still needed.
In the management phase the traffic should be monitored to spot and mitigate attacks early on. Also it is important to keep up to date with current attack vectors and security best practices.
Security in the API Lifecycle – The API Lifecycle contains security aspects in every phase.
API Penetration Tests
Penetration tests are a great way to test an API or a web application for vulnerabilities. During a penetration test, a trained and experienced team of cyber security experts checks if the API is vulnerable to the risks listed in the OWASP API Security Top 10 and other security risks. The scope and duration is discussed beforehand and any questions and expectations are clarified. For a smooth penetration test it is recommended to have good API documentation (for example using Swagger) and to have API collections which can be shared (for example using Postman). After the testing phase, a report will be written with all the identified risks, vulnerabilities and recommended countermeasures. This information helps to ensure the APIs in question are protected against attacks and can be used to further improve the security of the APIs in every phase of the continuous API lifecycle.
[1] https://salt.security/api-security-trends
[2] https://trends.google.com/trends/explore?date=2016-01-01%202022-05-30&q=%2Fg%2F11bwc74897
Our Experts Develop the Optimal Solution for You
APIs – OAuth – FAPI
Are you faced with the decision of how to best protect your APIs and customer data? Or are you already using OAuth and wondering if your implementation is secure?
We will be glad to advise you; contact us for a no-obligation initial consultation. Thus, we are at your side with the following services and solutions:
IT Security Consulting | Training | Penetration Tests
Don't hesitate and find your way to secure APIs with us. We look forward to supporting you with your projects.
Your Contact for OAuth and secure APIs
Dr. Christian Mainka
christian.mainka@hackmanit.de