What news from AWS re:Invent last week will have the most impact on you?
Amazon Q, an AI chatbot for explaining how AWS works.
Super-fast S3 Express storage.
New Graviton 4 processor instances.
Emily Freeman leaving AWS.
I don't use AWS, so none of this will affect me.
API Management / Security / Software Development

Beyond API Security Testing: Runtime Protection

The problem with API security testing is that it’s effective in identifying only some API security issues. That’s why Salt Security feels that organizations need to do more: with runtime protection.
Dec 15th, 2021 10:00am by
Featued image for: Beyond API Security Testing: Runtime Protection
Image par Sarah Richter de Pixabay.

Attacks against APIs are on the rise. According to Salt Security, 91% of organizations suffered at least one security issue involving their APIs in 2020. More than half (54%) of respondents said that they discovered a vulnerability in their production APIs. Slightly fewer (46%) said that they uncovered a problem that attackers could have used to try to tamper with their authentication schemes and thereby gain access to sensitive data.

API Security Testing to the Rescue

David Bisson
David Bisson is an information security writer and security junkie. He's a contributing editor to IBM's Security Intelligence and Tripwire's The State of Security Blog, and he's a contributing writer for Bora. He also regularly produces written content for Zix and a number of other companies in the digital security space.

Organizations can use API security testing to help address the issues discussed above. Linux Magazine noted that API security testing involves examining APIs for Broken Object Level Authorization and other common vulnerabilities identified by the Open Web Application Security Project (OWASP) API Top 10. Infosec personnel have an incentive to find these gaps, as they can bet that malicious actors will be looking for them. If they find an exposed weakness, those bad actors could potentially exploit it to compromise the organization’s systems and data. By contrast, if security personnel identify a vulnerability first, they can take action to either remediate the flaw or mitigate it in some way.

API security testing doesn’t only help to spare organizations the damages associated with a security incident. It benefits them in other ways, as well. This testing can bolster customer satisfaction, as it communicates that organizations are making an effort to protect their information against internal and external threats. It also provides an opportunity through which organizations can increase their revenue, as they can use API security testing to resolve issues so that they can release new features and products to market more quickly.

Such testing can take on various forms. For instance, static application security testing (SAST) refers to engagements where the tester has access to the architecture diagram or source code of the designated system or software. They can then use corresponding tools like source-code analyzers to review non-compiled code for flaws like input validation and path traversals. Binary and bytecode analyzers can perform the same functionality on compiled code, per Carnegie Mellon University’s Software Engineering Institute.

By contrast, dynamic application security testing (DAST) assumes the tester has no prior knowledge of the system. The tester will therefore use fuzzing to examine how the system handles invalid and unexpected test cases. They could detect scripting, data injection, and other issues in the process.

The Limits of API Security Testing

The problem with API security testing is that it’s effective in identifying only some API security issues. That’s why Salt Security feels that organizations need to do more:

Security test your APIs, but know that you will also need runtime protection to catch changes that don’t go through the standard build process and abuses that testing tools aren’t designed to find. If you do nothing else, focus on runtime protection as a way to “stop the bleeding,” slow down attackers, and buy time for application and API teams.

Security teams can ensure API runtime protection by activating threat protection features that might be available for their API gateways. They should do so as part of a multifaceted API runtime security strategy that takes different types of attacks into account. For instance, they need to ensure that they have measures in place that can help to mitigate a denial-of-service (DoS) or distributed denial-of-service (DDoS) attack. They also want to make sure that they can tap the big data, artificial intelligence, machine learning, and behavioral analysis capabilities needed to detect evasive API attacks.

Runtime Application Self-Protection (RASP) can help in this regard. As pointed out by TechBeacon, the purpose of RASP is to provide real-time protection against application attacks. It can monitor for malicious input or behavior on a continuous basis by intercepting calls from the app to a system, verifying the security of those calls, and validating data requests. All these features operate on the server on which the app is running, meaning that developers don’t need to redesign an app to accommodate its detection and protection features. As such, RASP can help identify and mitigate attacks without human intervention.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.