API scanning: So that interfaces do not become weak points

More and more apps and software means more and more application programming interfaces (APIs). If these are not extensively tested and properly secured, they could become one of the biggest sources of data leaks in the future.

Julian Trotsek-Hallhuber, Senior Principal Solutions Architect at Veracode, shows the relevance of the problem and possible countermeasures.

In autumn, the IT security activists from “zerforschung” succeeded in reading out personal data from the school app “scoolio”. Their access point was a poorly secured application programming interface (API). The data that could be called up was extremely sensitive: the app offers, among other things, the option of creating chat groups on various topics. The activists were now able to use the weak point to find out which groups individual students had joined. This in turn allowed conclusions to be drawn about the political, religious or sexual orientation of the users. Even if the school app is a particularly drastic and striking example, it is not an isolated case. The potential for API-related data leaks is huge.

APIs are everywhere

The programming interfaces are a very elementary part of today’s IT and telecommunications. Many aspects contribute to this, but above all the nationwide spread of smartphones and the triumph of as-a-service offerings. With the vast majority of smartphone apps, nothing actually happens locally anymore, they are more or less reduced to a user interface and data is obtained via APIs if necessary. In the meantime, sensitive areas of everyday life are also handled via smartphone, just think of banking, trading, or crypto apps. Health is also a growth market when it comes to apps. Everywhere APIs are involved in the communication of the applications. The situation is very similar with web applications. According to Gartner*, up to 90 percent of all web applications use public APIs and are therefore potentially vulnerable to this attack vector. Market researchers also assume that APIs will become the most common attack vector by 2022.

Not without reason, as broken or poorly secured APIs are a particularly rewarding attack vector for criminals, as they are specifically designed to share data. This means that cyber criminals do not have to familiarize themselves with complex processes in systems and collect data, they are practically served it on a silver platter. This is why insufficiently secured interfaces are such a big problem.

How does this even come about? Fragmentation and ever faster release cycles are forcing software companies to build more and more APIs faster and faster. Ultimately, this is just code in which errors can creep in. If speed is rated higher than security, problems can quickly arise.

Incidentally, whether an API is public or not does not play as much of a role in criminal practice as one might think. It is comparatively easy to get leaked internal addresses via the dark web. So companies shouldn’t feel falsely reassured about private APIs. These should be treated, tested, and protected in the same way as public interfaces.

Measures against API abuse

The programming interfaces are ultimately just code. Therefore, they should be tested just like other pieces of code. It is best to use a combination of static and dynamic analysis. As usual, the static analysis looks for formal errors in the non-productive code. As soon as the APIs are running, an additional dynamic analysis should be carried out.

Here it is advisable to rely on special tools for API scanning. Such tools allow security professionals to analyze their APIs as soon as they are available in a network-accessible runtime environment and before they are integrated into larger applications. API scan results are grouped by criticality and provide detailed vulnerability remediation guidance in a single dashboard along with other Dynamic Analysis scans.

This makes it easier for security teams to prioritize vulnerabilities and access the details developers need to quickly fix insecure code, enabling smooth collaboration between security and development teams.

An additional measure can be the analysis of the API documentation. This makes it clear which access options an interface offers. A whitelist can then be created to restrict access to necessary data types. However, such measures are not a substitute for extensive testing, because here the checks are only superficial and defective code cannot be recognized and fixed.

Conclusion

The growth of As-A-Service offers and mobile apps requires more and more automated data exchange. In almost all cases today, this is solved via APIs, so there is an enormous need for the programming interfaces. However, companies and developers should not forget that APIs ultimately only consist of code into which errors can creep in. It is therefore essential to test APIs extensively in order not to open the floodgates to cyber criminals in this way.