API Security Incidents Rise, Despite Confidence in Protection

Organizations are battling a rising number of targeted attacks on application programming interfaces (APIs) and while confidence in API protection is high, the onslaught of attacks indicates a disconnect between adequate protection and the semblance of security.  

A Noname Security survey of 600 senior cybersecurity professionals in the U.S. and UK found that while 71% of respondents have confidence in their API protection, a similar number of respondents (76%) experienced an API security incident in the last 12 months.

In addition, less than half (48%) of respondents said they have visibility into the security posture of active APIs, and nearly three-quarters (74%) of IT security pros said they do not have a complete API inventory or know which APIs return sensitive data.

The Challenges of API Security

Nick Rago, field CTO at Salt Security, explained that each API endpoint has its own functional logic, which means that each one represents a unique attack surface.

“As a result, API attacks are more behavioral. Attackers poke and prod for cracks in application logic,” he said. “A single endpoint may have thousands of different permutations of application logic an attacker may try to exercise after they learn the functional aspects of the endpoint.”

Rago added that IT security leaders often underestimate their risk, with many mistakenly believing, for example, that if they do not develop external third-party APIs for data consumption they have low risk.

However, he pointed out that APIs can be used externally for lots of purposes: Mobile applications, modernized web applications, B2B integrations and more.

“During our risk assessments, security leaders are often shocked at the number of unknown and undocumented APIs that are discovered and in use in their organizations,” he said. “It just takes a single unknown API to present a potential security risk.”

Scott Gerlach, co-founder and CSO at StackHawk, said many security teams are still getting it wrong by focusing on production monitoring as the primary means of API security.

“This requires staffing large enough teams to deal with the incidents and dealing with lots of incidents,” he explained.

Focus on Developer-First Tools

Finding and fixing API security issues early in the development life cycle with developer-first tools is an approach that results in more secure APIs, shifting production monitoring from the primary means of security to a backstop.

He said security leadership is taking a siloed approach to API protection, relying on internal security tooling and processes instead of partnering with engineering teams.

From Gerlach’s perspective, the best way to ensure APIs are secure is to integrate API security testing into existing engineering team workflows in the software development process.

“Put simply, many security teams are looking at API security too late—once the API has been shipped to production—or with legacy tooling that is not built for testing APIs,” he said. 

Rago said in addition, many security leaders think that their existing security stack can protect their APIs.

While the existing stack is still needed throughout the SDLC and all serve a purpose (code scanning, SAST, DAST in pre-deployment; WAF, identity, API Gateway in production, etc.), they cannot detect most of the low-and-slow behavioral API security threats that exist.

“These types of attacks are difficult to detect and proxy-based solutions miss API security issues, such as business logic abuse and authorization exploits,” Rago explained. 

He said organizations need to continue to evolve to be able to address API security holistically throughout an API’s life cycle, from design to test to production monitoring.

“In API security from a strategy standpoint, organizations cannot overlook the importance of proper runtime protection,” Rago said. “Flushing out application logic-based vulnerabilities in the development and test phases is extremely difficult.”

He argued that uncovering all permutations of application logic flaws during those phases is an unrealistic expectation.

“With API security, organizations need the ability to accurately discern user intent through continuous API visibility in runtime to detect and respond to threats in near-real-time,” he said. 

Gerlach said the lack of API visibility is a symptom of a broader disconnect between security teams and engineering teams.

“Engineering is iterating on APIs, running integration testing across new and existing APIs and ensuring quality API functionality,” he said. “Security is simply another form of quality testing.”

He explained that by addressing underlying cultural misalignment and collaborating early in the development life cycle, the API visibility problem will be fixed. 

Gerlach added that software is increasingly built API-first, with more and more companies becoming dependent on web APIs to power and enable their businesses.

“With this, more sensitive data ends up at the API layer and that is where risk is centralized,” he said. “Security teams need to partner with engineering early in the development life cycle to understand what APIs are being developed, what data they handle and how to best test the APIs for potential security issues.”

Nathan Eddy

Nathan Eddy is a Berlin-based filmmaker and freelance journalist specializing in enterprise IT and security issues, health care IT and architecture.

nathan-eddy has 277 posts and counting.See all posts by nathan-eddy