Can API Security Be Wholly Solved in Development?

It’s inevitable that gaps and vulnerabilities will make their way into production environments, no matter how much effort is put into security during the build and deploy phases. The following challenges help explain why:

Challenge: API-based Applications are Complex

Each API an organization creates has unique logic and therefore unique vulnerabilities. Most applications rely on a combination of APIs, increasing the mesh of logic. In addition, a variety of internal groups typically create the different APIs, adding more complexity to the business logic. These groups often make a range of assumptions about security, such as that another portion of the application has handled authorization, leaving gaps and creating points of exploitability.

Challenge: APIs are Constantly Changing

Thanks to agile development practices such as CI/CD, APIs change frequently – in just weeks, days, or in some cases, hours. At today’s speed of development, no security testing in the build phase can capture 100% of coding gaps and vulnerabilities.

Challenge: Zero-day Vulnerabilities Exist in APIs Too

Just like any other software, APIs also contain zero-day vulnerabilities. Just like with any other zero-day, you may not know it’s there until it’s exploited and someone makes off with your data or wreaks havoc with your services. If you’re lucky, a researcher or your own testing efforts will eventually find zero-days, so developers can eliminate them, but often it’s an attacker who gets to them first. Worse yet, the open gap stays open until the dev team can provide a fix. Typically, it takes days or months before you’ll become aware that a zero-day exists in your API.

Challenge: Secure Development Practices Require Continuous Learning

Teaching developers to be more security aware and to write more secure code is an ongoing effort. While developers continue to get smarter, the reality is that developers don’t think like attackers, and they never will. A developer builds for functionality and efficiency, thinking “How do I make this feature work?” An attacker looks for ways to get features to do unintended things, instead thinking, “What will happen if I do this?”

Challenge: Scanning Solutions Miss the Bulk of API Vulnerabilities

Most of the security mechanisms applied in development revolve around scanning code. Scanning tools help in certain areas but fall far short of providing full security. Note Gartner’s take on the demise of the RASP market in the 2020 Application Security Hype Cycle: “[RASP] has failed to live up to its potential because of the complexity of its interaction with both applications and the surrounding ecosystem…”

A major shortcoming of scanning tools is their dependence on signatures and configuration. Also, because of their expense, they are often deployed in a limited fashion, focusing only on primary applications. Signatures are often out of date, configuration is never perfect, and you won’t cover all your applications with scanning.

The biggest reason scanning won’t solve your API security challenge is that these tools provide very limited coverage across API vulnerabilities. As an example, Broken Object Level Authorization, the #1 vulnerability in the OWASP API Security Top 10, is not a vulnerability that code scanning will identify.

Challenge: Penetration Testing and Bug Bounties Provide Only Partial Coverage

Just as with scanning tools, penetration testing and bug bounty programs provide only partial coverage in identifying API vulnerabilities and gaps. As with any security initiative, applying limitless time and budget will help you approach 100% coverage, but no customer has such a luxury. As a result, organizations must focus these programs on just their primary applications, leaving gaps.

Combining Security Efforts Across the Release Lifecycle

DevOps teams dedicate significant time and effort to identify and eliminate gaps early in the development cycle, before releasing APIs into production. At a certain point, though, spending more time identifying, prioritizing, and remediating security gaps in pre-production stands in the way of rapid app dev practices and with API-based applications, many gaps do not surface until they’re in production. Organizations succeed when they combine security efforts across the release lifecycle to include pre-production, runtime, and post-production.

Our customers benefit from runtime protection to identify and stop attackers early during reconnaissance as they try to uncover and exploit zero-day vulnerabilities. In addition, details of an attacker’s reconnaissance efforts provide invaluable remediation insights for development teams to eliminate gaps in post-production. By essentially using attackers as penetration testers, developers clearly understand what in the API is vulnerable and how to eliminate the gap. As a result, development teams can more easily prioritize their remediation efforts, be more efficient in their remediation, and improve workflows. Remediation insights also improve secure development practices so developers release code with fewer gaps and vulnerabilities in the future.

Visit https://salt.security/demo/ to learn how Salt Security makes it safe for you to innovate by protecting your APIs.

‍

‍