API Security Needs Substantial Improvement

Posted on by Robert Ackerman

As developments continuously evolve and grow in the digital world, it’s a slam dunk that cybercriminals will follow suit and do what they can to undermine the progress. Among the best of many such examples is the proliferation of application programming interfaces (APIs) – the mechanisms that allow two software systems to interact and make the staggering volume of internet content ever more robust.

And, of course, hackers are all over this development. 83% of web traffic today is attributed to APIs, which are critical to driving digital transformation, and this ubiquity has made it the biggest attack vector of all for applications, according to Forrester Research.

All types of web sites are victims, and Internet of Things (IoT) appears to be on the path of becoming the single biggest target. Crucial and sensitive data is constantly transferred between users and APIs and the applications and systems in which they interact. IoT has weak security. Insecure APIs are also common, making IoT an especially easy target for hackers.

At this juncture, it’s almost an understatement to say that API attacks are rising at a torrid pace.

A recent survey of cybersecurity pros by Salt Labs, a Silicon Valley-based API security company, found that a whopping 94% had a security issue, especially a vulnerability problem, with their production APIs over the past year. Even more worrisome, Salt Labs identified a significant rise in attackers targeting its customer base. Its last such study, at the end of last year, found that 4,845 API attackers were operating in December 2022 alone – a 400% increase from just a few months prior.

These numbers underscore the sad fact that API is sub-par too often. The timing couldn’t be worse, given that reliance on APIs is at an all-time high and critical business outcomes rely upon them. Unfortunately, says Salt Labs, only 12% of respondents’ organizations currently have what they consider to be advanced API security strategies, including dedicated API testing and runtime protection. This is unfortunate because traditional approaches to API security, such as reliance on API gateways, have been falling short.

Why does this persist, even though API attacks are exploding? One answer, say API experts, is that APIs too often are released into production faster than a security team can review and catalog them. In some cases, the security team doesn’t even have visibility of all the APIs that were developed and released.

This leads to the creation of so-called shadow APIs that are invisible to the security team and API gateway. The primary issue with shadow APIs is that they have access to the same sensitive information published that secure APIs do, but no one knows where they exist. A sister problem is so-called aging zombie APIs that haven’t been properly disabled and become a dormant breeding ground for cybercriminals.

Yet another issue is that APIs are changing constantly and documentation – the first step in protecting APIs -- often fails to keep up.

Even when it does, the pressure to get it done swiftly sometimes leads to documents riddled with errors. API documentation is technical content that describes the API in detail. It also includes instructions on the effective use and integration of the API, with an emphasis on security constraints. Getting things wrong is unacceptable.

What, if everything, is the solution?

A big step in the right direction would be a strong partnership from the get-go between SecOps teams and DevOps in the creation and execution of their security strategy. This would require new technology and processes to help establish a frictionless relationship --- one in which both sides get what is needed to be successful. Software developers must be able to move fast and innovate. Security pros, meanwhile, need full visibility into API behavior to monitor suspicious activity and react as soon as trouble occurs.

Also required is a feedback loop between DevOps and SecOps teams designed to help these teams work in concert. The goal is twofold: Streamlining application release workflows while delivering an optimal digital experience and getting security risks under control.

In the meantime, companies must embrace API security best practices. These include:

+ API discovery and inventorying. API continuous discovery and inventorying of APIs is essential for effective security measures. APIs can be secure only if the right people know they exist.

+ Identify API vulnerabilities and associated risks. An important requirement in the API checklist is proactive API threat detection and protection. Ignoring API vulnerabilities and risks is dangerous.

+ Enforce strong authentication and authorization. Each plays a different role, but these two API best practices work as powerful tools for API protection while implemented together.

+ Incident response. Data breaches, at times, are unavoidable. In such cases, having a robust incident response plan is essential because it enables organizations to bounce back quickly and minimize the impact of breaches.

These steps take work. But these and others, including the aforementioned partnerships between DevOps and SecOps teams, are doable. On the latter front, it might seem as though SecOps players might have to test each line of code – one by one – to make sure it’s secure, seemingly impossible in the business world. Fact is, automated tools can handle this particular task. The point is that all API players need the right attitude. With it, they can do a lot better than they are doing today.  

Robert Ackerman

Founder/Managing Director, AllegisCyber, AllegisCyber Capital

DevSecOps & Application Security

Network / Infrastructure Security API Security Internet of Things authentication incident response

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment. Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA Conference™, or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.

Share With Your Community

Related Blogs