Why is API security so difficult to manage?

2.1k views3 Upvotes3 Comments

Chief Technology Officer, Self-employed
There’s an old saying in security: “Your defense must be informed by the offense.” In general, defenders are always one step behind the aggressors, whether we’re talking about the digital or the physical space. 

The Maginot Line is a good analogy for the current state of API security in most organizations. The industrial revolution didn’t happen in order to build machine guns, it was for commercial reasons. But these innovations created new military capabilities and in 1914, defenders in Europe didn't anticipate the degree to which the attackers were embracing industrialization in the context of kinetic warfare. Unfortunately, this meant they went riding into battle to defend their homelands on horseback, only to be met by mechanized columns of machine gun fire. After that conflict, in 1930, the best military minds in Europe began construction of the Maginot Line, which was an amazing set of fortifications built to resist a robust ground invasion like the ones they had just endured. But only 10 years later, the next attacks went around the Maginot Line through Belgium and the Luftwaffe flew right over it. The Maginot Line, as impressive as it was, provided a false sense of security and failed to take into account the next set of innovative thought patterns of the attackers. This is basically what we’re seeing in the world of web security, and these same rules apply to what’s happening across the world as companies rapidly create and expose their APIs. 

We've been dealing with and securing web apps for over 20 years, but 20 years ago they were built much differently than they are today. The legacy term is “monolithic application,” and that was a standard design pattern for years and years; many companies still operate this way. There’s a well-known application security model from an organization called OWASP, and while it’s still valid, it was first published in 2003. You still have to defend against the attacks from the original OWASP Top 10, like SQL injection and cross-site scripting (XSS). But now companies and governments are rapidly embracing APIs and microservices, and in doing so they're expecting these new exposed services to do a lot more of the security that used to be centralized. The “I” in API stands for interface, and publishing new interfaces changes your attack surface. Attackers always change their tactics to take advantage of new attack surfaces, and if your defenses don’t evolve in real time, you are left with gaps and undefended blind spots. A lot of security and development teams don’t know that OWASP published a new Top 10 specifically for API vulnerabilities beginning in 2019, so unless they’ve revisited their whole framework in the last year or two, there’s a very good chance that they haven’t taken these new attack vectors into account. 

Going back to the Maginot Line analogy: they didn't have anti-aircraft capabilities when they built it because air power wasn't a big thing, so they had to adapt during battle and learn how to defend up, not just left and right. In the same vein, we need to increase our abilities to defend against the new attacks against APIs, but today API adoption is dramatically outpacing security and the longer this happens, the further apart adoption and security get. There's a huge paradigm change from monolithic applications and the old attacks to the new, distributed API and microservice attack surface. The changing attack surface is one thing, but another is what’s available on the new attack surface. APIs expose application and business logic directly. That's not a bug, it’s a feature. It's by design, but the defenses like web application firewalls (WAF) that we use to defend against the old Top 10 list can’t understand or defend against logic-based attacks. 

Yet another aspect of modern application architecture is that you can have multiple teams iterating and changing their APIs quickly. Some folks change their APIs several times per week and sometimes several times per day, and security can’t keep up with these changes. But once you fall behind, it's very difficult to catch up. As API security is a very new space, I use the Maginot Line analogy only to provide a non-computerized historical perspective. This paradigm happens over and over again, and in 10 years, it'll be something else. But for now, when it comes to API security, we're all behind the curve and it's become a big problem that is only getting worse, at least in the short term.
Senior Information Security Manager in Software, 501 - 1,000 employees
Is it really that hard to manage? If you have a system in place to manage it, is can easily be done.

API security takes an investment and if that investment is done, then it is easily doable.

The key is API security testing and API access control. Lots of new and existing products coming out to manage that.
Director of IT in Software, 201 - 500 employees
A few things come to mind:

Lack of visibility - there are tons of APIs being created and modified daily, and it's hard to keep track of all of them.
Exposed wide in the open - Many times, Developers will expose their APIs or a subset of them in front of the firewall while they do testing, are showing them to a partner or if a 3rd party is having issues accessing them. The security team is sometimes unaware of this, which goes back to the first-team lack of visibility.

The false belief that APIs are secure by nature - I see this notion other where it's believed that the APIs are supposed to be open and secure by nature, which is not always the case. While almost everyone in IT knows that a VM should not be connected to the internet directly, it needs to be behind a firewall with AV installed, patches etc., so this is a no-brainer. The opposite applies to APIS; you need to remind teams that APIs should be treated similarly.

And there are the inevitable comments, "Well, there is nothing important in our APIs" or "They are not worth hacking."

I think it's a combination of mindset and not knowing how to secure the APIs properly.

Content you might like


Yes, but third & Nth parties are still a concern39%



Don't know1%



CTO in Software, 201 - 500 employees
Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.
Read More Comments
47k views133 Upvotes324 Comments

First day on the job10%

Sometime during their first week52%

Sometime during their first month26%

2-3 months after their hiring date6%

It depends on their role/level3%

Other (explain in the comments section)1%