Developers should take a look at the API Security Top 10, because attacking an interface is highly interesting for hackers. In order to better secure sensitive endpoints, the OWASP Top 10 creates a list of the most common vulnerabilities in programmed interfaces. A lack of protection can lead to the outflow of sensitive data on a large scale.
OWASP create another list for the security of APIs.
In the IT security industry, the OWASP Top 10 are a number. Everybody knows them, courses build on them and they are usually discussed during the studies. Seldom is there agreement in the scene. Now the Open Web Application Security project goes one step further and creates extra security or attack surfaces for interfaces. 10 security holes that can have an impact on API security.
Admittedly, capable developers who know the vulnerabilities and intercept them during programming are the best means of choice. But a pentest brings certainty. With the API Security Top 10, a common framework is now created. The importance of this list is fueled by Gartner. It is assumed that by 2021, 90% of the attack surface of web applications will run over the programmed interfaces. The project has agreed on the following Top 10:
|1.||Broken Object Level Authorization||Endpoints of the interface accept IDs without checking the client for authorization.|
|2.||Broken Authentication||The necessary logic behind the authentication process often has gaps. Auth tokens can thus be exploited in different ways.|
|3.||Excessive Data Exposure||Sensitive data is passed on to the client. The task of filtering then lies with the client.|
|4.||Lack of Resources & Rate Limiting||The programmed interface has no limitation on the number of requests. Brute force and DoS attacks are then possible.|
|5.||Broken Function Level Authorization||The undefined separation between administrative and regular functions leads to possible access to otherwise restrictive resources|
|6.||Mass Assignment||Delivered data is directly transferred to the data model without segmentation or filtering. Attackers have different ways of gaining access to other objects.|
|7.||Security Misconfiguration||A common problem is the default settings. They often result in the insecure standard regarding Cloud Storages or HTTPS headers|
|8.||Inection||An API may also be vulnerable to a SQL injection. The most common problem with web applications|
|9.||Improper Assets Management||Careful documentation should prevent accidental release of unsupported APIs and debugging endpoints.|
|10.||Monitoring & Logging||Lack of logging and monitoring leads to a long detection rate of attackers.|
A case of Excessive Data Exposure was noted in the case of the Mobile World Congress 2020 website.
To prevent the exchange format from becoming a data slingshot: A pentest on the API!
Although many problems can be intercepted by modern gateways, this should always be the last hurdle, but never the protection mechanism itself. As before, inputs should be validated and developed according to the security by design principle. Then already a large attack surface can be reduced. Even if some vulnerabilities overlap with the classic OWASP Top 10, these security holes in the area of APIs must also be detected and closed. This can be done in the form of a penetration test. Then the API security in general can be increased.