Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth, I'm the director of the Practice Identity and Access Management here at KuppingerCole Analysts, but our today's topic is not identity and access management. My guest today is Alexi Balaganski. He's a lead analyst with KuppingerCole and he's the CTO of KuppingerCole Analysts. Hi, Alexei, good to have you.
Hello Matthias. Thanks for having me again. And yeah, although you just mentioned we are not talking about identities, but we actually are. Because identity actually plays a huge role in API security and I would argue, in cybersecurity in general. So you are absolutely not out of your water today. It's really a great point to bring before we even jump into this whole API Top 10 risks and whatever we wanted to discuss. And actually, I do have two reasons for bringing this subject to another episode of our podcast. First of all, we just launched an updated version of out Leadership Compass on API Management and security. The last one we had was about two years ago in 2021. The new one will be released later this year and I expect quite a few interesting changes in the field as we will see immediately. And the second reason is OWASP, that very well-known Open [Web] Application Security Project organization has just released a new version of the API Security Top 10 risks. And again, as an industry veteran, you're probably familiar with OWASP, right?
Right. So if I think back on OWASP, I think of the traditional web programing, web surfer style and also web design errors and risks that this OWASP very early also pointed out. So directory traverse and all these kinds of mishaps that could happen when programing a web service. But they have extended their scope over that and we have been talking about API security earlier and they are talking about API security finally as well. So this is a major change for them?
So, yes, you're right. I mean, OWASP, if I remember correctly, was established over 20 years ago when API or not even a thing. But they have definitely evolved beyond just traditional applications and application security. And yes, since 2019, they are actually covering API security as a separate subject. And back then they have released their first OWASP API security top 10, highlighting the Top 10 risks they believe were influencing the APIs and their growing proliferation. And yes, it was a major event for the entire industry because again, OWASP is an extremely old and well-respected organization, a lot of vendors rely on those lists to highlight the product capabilities. And for years we were actually struggling to explain that, No, API security is not the same as web application security. And you cannot just cover of the traditional quote unquote old school risks and feel content and safe. No. And finally, about 4 years ago, we had this officially recognized by OWASP. And again, just last week, I believe they released the version 2.0, if you may call it that way, the OWASP API Security Top 10 for 2023. And this is what we're going to discuss in some detail today.
Right. And I think this is absolutely necessary because when we think of today's ways of creating applications, APIs are a key foundation and securing them properly is also for web applications and every type of type of application, mobile applications, whatever you want to have, they are a key component. And getting to these APIs in a secure manner and to integrating them well is essential for today's ways of creating modern cloud native applications as well. So but if you think of this OWASP Top 10 as a Top 10, so these are the ones that you should most probably take care of, especially. So when we look at the list, what are the main API security risks that they come up with that organizations, that developers, that security pros should look at?
Well, before we dive into that. Let me just add a few more general words. Like, for years, the industry and the general public have recognized API as a kind of a subset of web application technology, because in a way that's true, the traditional REST-APIs are based on the same protocols and standards, whatever. So in a way most people believed, used to believe, and some still believe that API security is a subset of a general web application security field. It used to be like that perhaps 15 or ten years ago. Nowadays the situation is completely opposite. Nowadays, I would argue that web applications are a subset of API security because not only modern web applications and websites are built on the APIs, but just the way they are designed now. But you also have like microservices and cloud native workloads and industrial IoT fleets and whatever other areas of modern IT which are powered by APIs like 100%. Though if you are dealing with those fields, you have to keep API security really close to your heart and you have to stay on top of the modern risks. And this is exactly where the new Top 10 list actually addresses some of those changes. But still, the first, the top security risks for API is still the same. The so-called broken object level authorization. It was recognized by that four years ago, and it still remains the number one priority for everyone. Explained simply, it's basically not giving too much or not giving enough thought to authorization while designing your API. The most trivial example would be, suppose you just registered a new account in an online shop and you know that your account ID is 123. So you can use an API to request your profile information, your order history and stuff like that, using this ID 123. But what if you use 121 instead? Or any other ID you could just enumerate easily. Some APIs are just not designed to protect other people's accounts from such kind of trivial but very common attack. They will readily give you or someone else's profile information or someone else's bank account status, or even allow you to basically perform an operation for some other user. This is broken object layer authorization. It's still the top security risk and the top API security problem in the world. And there is absolutely no way a tool can fix it because it loses all deeply rooted in our business logic and application design. But on the other hand, it's deeply rooted in identity. So it's your playing field, basically, not mine. So we have to think about it together. And of course, the second most risk is also in your field. It's broken authentication. It's even more trivial kind of an attack. What if your API just doesn't have any authentication at all? You are exposing some kind of business logic, which is supposed to be secured, but it's not game. U.S. Federal Post, Instagram, Facebook, huge vendors, even security vendors, are known to be victims of this kind of attack. We just have not thought about securing an API because nobody will find it. It's something small. It's something internal. It's an API to power your office printer. But again, with all the hyperconnected modern networks and exposure to the world, it's often enough to compromise your entire regulation.
Right. And if you say authentication and authorization, these are the main aspects of identity and access management. And also just getting to broad access is already an issue. you mentioned the example with guessing another ID and trying to access that, even if you get a access denied, that might be already too much of disclosure because that shows there is an object but you don't have the right to see it. Even that disclosure of data is a risk.
Let's just kind of go through the list and see this is exactly where they are addressing this kind of risks. And one thing to point out, by the way, on the second risk about the broken authentication, they used to call it broken user authentication, not anymore. They finally recognized users are not the only parties participating in an API economy. You have devices, you have IoT fleets, you have microservices and other applications or robots, whatever, AI accounts maybe. So it's no longer just about people, any kind of authentication is equally important for API security. And yes, just as you are telling about the other aspects of access management, broken object property level authorization is number three risk in the new list. It's a new addition. It was not in the old one, but it's extremely relevant because basically it says, yeah, objects are complicated data structures which are usually the bread and butter of any API. When you develop a distributed application or a service, objects are representations of your business logic. It could be a product, it could be a user, a financial transaction, weather forecast, anything. It's an object. It has different properties. And very often developers protect the object as an entity, but forget the different properties of that object can have very different risk levels of their own, because especially when developers are relying on automated tools to convert a complicated structure into an object, you might forget that, I don't know, user level, for example, should not be a modifiable property because you could easily elevate a normal user to an administrator if your API allows it mistakenly. So this kind of attack is again extremely trivial to implement and it's extremely easy to forget about. This is why it's a new number three Top risk for API Security. Moving on, number four is now called unrestricted resource consumption. It used to be called something like lack of rate limiting, which was more in a sense of what traditional web application. Basically, if your API is not protected from a denial of service attack, it will fail. So your business logic won't be available. Your business will stop. You will lose money. That was like the old way to see the problem. Now they finally recognized that unrestricted resource consumption goes beyond that trivial example. First of all, we have new types of APIs like GraphQL, where you can run really complicated queries through an API endpoint. And even if it's just one query and not 10,000, it could still break your backend server, if it's not secure, if it’s not implemented properly. So absolutely, resource consumption risk unless you have specific tools and technologies in place which prevent not just from the lower level network denial of service attacks, but also high level logic bombs and stuff like that. Number five is broken function level authorization. Again, authorization. But now it's about function level. And again, it's very easy to understand from the developer perspective. You know, traditional REST-API, for example, you have a GET method which would retrieve an object from a back end and the PUT method which would modify it From a rational person's perspective, these are absolutely different operations. They have to have different access level protection, right? I mean, I can, for example, read a document from your research library, but I cannot modify it because I am not the author. You know it, I know it. Developers often forget about it. So this is the number five risk in this list. Number six is another new addition, lack of protection from automated threats. It's probably replacing in the old list, in the old list, they have this injection risk, which was highly technical and referred to a more narrow class of attacks. Now they just recognize that there are so many other attacks which can be employed against APIs. And the risk of automated actors doing this is not just technological, it's also very tangible for businesses. A trivial example would be, you have an online service selling concert tickets. The second you enable your new show to be sold on your service, a band of bots come and buy all your tickets, or some scripts. Like 5 seconds later, all the tickets are sold out and now 5 minutes later you find those tickets on eBay with much higher prices. So it's a trivial example, but it also happens to other business areas as well. And of course, bots can be used to perform injection attacks and other lower level attacks against the API. But then again, the new list goes level higher to recognize that yes, you have to think in the much more business related terms, even when dealing with automated threats. And of course you have the AI actors to think about now. It's much more sophisticated than just scripts. Number seven in the list is server side request forgery. Again, it's a completely new area of risks for APIs, which sounds highly technical. And we probably could spend another half an hour talking about just this one. And a very high level explanation would be you have to think that your API might need to reach another API during a transaction or just another external resource. Usually, for example, your service could get a URL as an input and you would call that URL. But what if that URL contains malware? What if that URL is actually another API, which a third party hacker wants to exploit? They cannot directly DDoS that third party API, but they can exploit yours as a workaround. So developers have to take extremely high precautions against working with third party addresses, network resources. So just know what's going on behind every URL and behind every API and network port, because not only you can violate some policy, you can also bring down an unexpected API, even if it's actually protected from the internet. But you provide a workaround for the hacker. This risk alone is just at a new level of complexity to this whole API security. Because now you not only you have to protect your API in question, you have to know what's going on around your API, your network, maybe even your partner networks, and maybe even in some third party areas as well. And it's, in a way, it’s still your responsibility. I would argue that this is probably like the most important eye opener for the newcomers to the API security, because this rule alone says, you are responsible for much more than you probably anticipate. Number eight, another new addition, security misconfiguration. It was in the old list, it remains here as well. Again, this is probably for a lot of people, this is like the heart of API security as a field and many people would mistakenly believe that this is the only problem they have to care about. Protecting their API infrastructure Again, security misconfiguration is a huge problem for real life data breaches and attacks, but it's definitely not at the highest position. It's still important and you still need specialized tools to actually monitor your API, quote unquote security posture, among other things. And yes, you still have to monitor and secure and operate and patch and whatever your infrastructure. It's still there in the list, but it's arguably less important than many people believe. The next one is number nine improper inventory management. It used to be called assets, now it's called inventory in the new list. Small change, seemingly, but again, this reflects the idea that you have to think about much more than just a list of your API gateways for example. It's no longer just about technological assets, IP addresses, URLs, endpoints, whatever. It's all about every part of your API chain, from the security stack to the actual back end, to the data, which is actually served through the API. And going even further to the people operating that stack and the service accounts exports through the stack. So it's much more than just basically having your APIs in an inventory. There are so many more blind spots which can go from documentation to network asset management to even higher level business areas. And all of that has to be taken into consideration. And all of those inventories have to somehow work together to give you this proverbial single pane of glass, constant visibility of not just what's going on with my API, but also what's going on in this whole, for the lack of a better word, supply chain, where an API is probably just an end point in a long process. And the last one is number ten unsafe consumption of APIs. It's a great addition and again, a great point to emphasize that the scope of API security is much broader than just dealing with your APIs, because serving an API is unsafe, but consuming someone else's API can be just as dangerous. So you have to include third party APIs, partner API, it's public APIs, low level service management APIs, printer APIs, Kubernetes APIs, cloud interfaces, whatever. You have to include in your inventory management and you have to take care of securing those as well. It's just as much your responsibility as from those people who actually manage those API for you.
Right, now that we've heard this list of risks, and these are “just” the Top 10, quote unquote just the Top 10, this is a lot of work to do, just fixing issues that are related to these ten API risks. But from a strategic perspective, what would be your recommendations when starting to look at this Top 10 list, and at API risks in general, where to start, what not to forget, and where to put focus on?
Right. So first of all, again, I really like the new updated list because it includes a few crucial additions which are so relevant for less technically inclined and more business oriented people to understand that yes, they have to focus on many more things that they anticipated. Perhaps. The old version was slightly more confusing, I guess. But the biggest problem I personally have with any Top 10 list, be it travel destinations or foods to try or API security risk to think about, is that for some people it would seem that the list of risks ends with those ten. No it doesn't even begin. So yes, you have to deal with every one of those Top 10 risks. But you have to remember there are another 10,000 in that huge long tail of security risks you also have to deal with. And this is why in our Leadership Compasses on API security, we always push this idea that there is a API lifecycle which starts long before you actually write code for it. It starts in the early design stage where you define the entities, the consumers’ identities, if you will, and roles and access levels for those business objects. And even before you transform them into classes and codes and endpoints, you already have to start thinking in security terms and you cannot stop until the very last moment your old legacy API is finally taken from production and retired. So this whole lifecycle needs to be secured and monitored and protected from automated threats and whatever. So although not only all those Top 10 risks apply continuously, but you have to keep in mind that the list doesn't end there at all.
You're you've mentioned that you are already in the process of updating that Leadership Compass and as the importance, as we've discussed, of API is increasingly growing you are also looking into these services and products that provide API security. So how does that work? Do you rely on the statement of the vendors saying, Yeah, we are happily dealing with this risk that is on API Security Risks Top 10 place seven? And how do you verify that this is the case?
I would actually argue for every potential API security customer looking out for a solution to not specifically ask a vendor whether they can fix those Top 10 risks because they probably can. They surely can. This is a huge marketing buzzword, but again, you have to look behind the buzzwords, have to look behind the label, you have to focus on specific capabilities which are needed for your API, for your partner API, for the whole API ecosystem to be consistently protected. And this is exactly what we do in our Leadership Compasses. First, we identify those key capabilities and explain why we believe those are actually the key ones you have to be looking for. And then we measure every vendor against those access and our final score looks like a kind of spider chart. If it's close to a circle, then the solution is perfect for every capability. But unfortunately, most solutions usually look like a seastar. So only covering a few of those capabilities sufficiently enough, but maybe lacking in some others. And it's up to you to understand your priorities and decide which risks you need to address first and which could be delegated for a later solution. This is exactly what we're focusing in our Leadership Compasses, and I definitely recommend everyone to check our website, not just API security subject, but other related and unrelated topics. And again, to not forget about identity, we do offer a lot of research covering those areas as well. And even if there is not a single mention of API in those documents, they are still very, very relevant for API security as well.
absolutely. And I like that that explanation that you just provided because otherwise, if I was an attacker, then I would of course say, okay, let's skip the first ten and maybe skip the next ten and then use and exploit those vulnerabilities that are starting with 21, 22, 23 and try to use that to get access to these systems. But if you change focus and move over to capabilities, then you are more likely to have those covered, right?
Absolutely. And of course you should not forget the old proven principle of defense in depth. API Security alone won't protect you if your database backend for example, is exposed through a completely different attack surface. So we have to think strategically. But then again, that's a story for a different episode.
Absolutely. And just to summarize that, you said that this is just work in progress. You are working on that Leadership Compass, on that update. And I hope and I think it will be available when we come to our next flagship event that will take place in November in Frankfurt, the cyberevolution will take place. And I think API security as a modern trend in cybersecurity, but also just an important topic to cover will also play an important role at cyberevolution in Frankfurt. If you're interested in being there, just reach out to our website. If you want to speak there, just reach out to our events team and apply for a speaking slot and present your experiences in cybersecurity as well. So I'm looking forward to seeing you, Alexei, there in November. I'm looking forward to seeing you much earlier as well, and I am looking forward to this update of the Leadership Compass. Any final additions from your side before we close down?
No, well, again, thanks a lot for having me. Thanks a lot for giving me another opportunity to bring up this very important but often overlooked subject. Yes, API security is much more important than some people still believe. And yes, it will be a part of our new flagship security event. So definitely see you there. I hope to meet some new people as well and maybe ensure that we'll talk about security and it's various incarnations and let's not forget, API is just one single subject and we have to work, we have to ensure that everything is compliant and secure and protected from any potential attacker path and any risk vector and whatever you name it.
Absolutely. And let's close this with security in depth. I think that's the final message that we should take with us with API security being a building block. Thanks, Alexei, for taking the time. Thank you for bringing up this important information and really highlighting that challenge here. And the OWASP Top 10 API security risks readily available, lots to learn as well. Thank you and bye bye
Thanks, bye.
