Subscribe
Share
Share
Embed
The 2025 API Threat Report is out, and shocker: we’re still getting wrecked by injection, data leaks, and BOLA. That’s Broken Object Level Authorization, for those of you keeping score at home. And here’s the kicker—95% of these attacks are coming through authenticated sessions. Translation: the bad guys aren’t breaking in through the side door, they’re waltzing in with a valid badge and looting the place. But sure, let’s keep obsessing over password complexity policies while ignoring that our APIs are basically vending machines for sensitive data.
In this episode, F5's Lori MacVittie, Joel Moses, and special guest Garland Moore dive into BOLA misconceptions, the impact of AI, and solutions you can implement now to mitigate risk.
Creators and Guests
Host
Host
Lori MacVittie
Distinguished Engineer and Chief Evangelist at F5, Lori has more than 25 years of industry experience spanning application development, IT architecture, and network and systems' operation. She co-authored the CADD profile for ANSI NCITS 320-1998 and is a prolific author with books spanning security, cloud, and enterprise architecture.
What is Pop Goes the Stack?
Explore the evolving world of application delivery and security. Each episode will dive into technologies shaping the future of operations, analyze emerging trends, and discuss the impacts of innovations on the tech stack.
00:00:05:03 - 00:00:33:07
Lori MacVittie
Welcome back to Pop Goes the Stack, where we just don't track emerging tech, we test its failover plans because it's always DNS, right Joel?
Joel Moses
That's exactly right.
Lori MacVittie
That's right. I am Lori MacVittie, your snarky sysadmin for today and most of the future, and we are here because we've all got the BOLA blues. Why? Because we read the 2025 API Threat Report.
00:00:33:09 - 00:01:00:26
Lori MacVittie
And shocker, we're still getting wrecked by injection, data leaks, and BOLA. Right, so that, what's BOLA? It's broken object level authorization. And, you know, 95% of attacks are coming through that these days. So translation, the bad guys aren't breaking in through the side door, they're waltzing in with a valid badge and looting the place. Okay.
00:01:00:28 - 00:01:24:12
Lori MacVittie
Bad stuff. BOLA's been at the top of the OWASP Top Ten for for apps, APIs, and soon probably AI too, for like the last six years; since like 2019. I, it likes to switch with SQLi, but you know BOLA is big. And so we brought Garland Moore. Welcome, Garland.
00:01:24:15 - 00:01:25:20
Garland Moore
Hi. Thanks for having me.
00:01:25:23 - 00:01:43:00
Lori MacVittie
Awesome to talk to us about BOLA. What's going on? Some real life examples maybe, and even some advice on how to stop it because it's a real problem. So let's kick it off. What the heck? What's really BOLA. What's really going on?
00:01:43:03 - 00:02:02:01
Garland Moore
Yeah. Yeah. Thanks. Like, like I said, again, thanks for having me. BOLA is one of those things that, you know, it's on the OWASP Top Ten for a reason, right? It's number one on the top ten. And the reason being is because it's the most common, but also the most impactful vulnerability when it comes to APIs. Right?
00:02:02:01 - 00:02:29:24
Garland Moore
So, when you think about this concept, one of the misconceptions that we commonly run into is most people think that, oh, I have authentication so I'm good. But authentication and authorization are two different things. So when you commonly think about okay, I've got authentication within my app, but the authorization piece is commonly missing. So, and that's one of the reasons why it's highly targeted,
00:02:29:24 - 00:02:36:07
Garland Moore
right. Because those two things get get construed all the time and they really need to be separate.
00:02:36:09 - 00:02:56:23
Joel Moses
Yeah. So let's, let's let's kind of walk through a BOLA attack, and kind of provide an example. Let's, let's look at an API surface. So, say I'm, I'm a logged in user and I'm accessing an API endpoint and I'm checking my account. And, so, I would issue a get request to the API account slash and then give an account number,
00:02:56:25 - 00:03:23:09
Joel Moses
right. And if, and my account number and my authentication may suggest that I have access to that account, but if I'm not doing a secondary authorization check to see if my account number and my authentication are the same and authorizing me into something, then I can I can simply change my account from 1-2-3-4-5 to 1-2-3-4-6 and then see the next account over.
00:03:23:12 - 00:03:27:09
Joel Moses
Is that how that that attack occurs?
00:03:27:11 - 00:03:52:24
Garland Moore
Yeah, absolutely. That's exactly what happens. And what can happen in that instance is, as a user, I now have access to data that maybe I shouldn't be able to see, right. The API didn't check to see, hey, was I allowed to access that information. Or you know, was that user string that I put actually tied to the person who was authenticated to the application?
00:03:52:24 - 00:03:55:17
Garland Moore
So yeah, absolutely, a huge problem there.
Joel Moses
Got it.
00:03:55:19 - 00:04:13:28
Lori MacVittie
Yeah, it sounds like there's two pieces to this. On the auth authorization side. I mean, assuming we all get authenticated, we have to log in and do all the 'here's your security code' and 'check your email,' and it annoys us, but that makes sure we are who we say we are. We have authentication; I am an identity. Wonderful.
00:04:14:04 - 00:04:42:25
Lori MacVittie
But then you have that authorization piece and it sounds like there's more than just, right, authorization is who are you and do you have access to to that object? Not just any account, but all, you know, this particular account. Like there's a level of authorization of policy that may not be in place, as well as just a failure to check it. Because if the policy says, "oh, they have access to accounts," then it's still broken, right?
00:04:42:27 - 00:04:45:28
Garland Moore
Right, right. Exactly, exactly.
00:04:45:28 - 00:05:13:25
Joel Moses
Lori, this seems to me to be something that a developer assumes is true but fails to check. A developer might assume, for example, that an authenticated user is authorized and failed to check whether they are or not. So, at the point in time when they're they're supposed to be allowed access to their account and their account alone, the assumption the developer makes is an authenticated user is also authorized to that account, and it skips past the secondary checks.
00:05:13:25 - 00:05:20:06
Joel Moses
So, you know, I think one of the solutions to this is to simply think about this in zero trust terms.
00:05:20:09 - 00:05:43:18
Lori MacVittie
Yeah, but zero trust doesn't say shift everything left and say, well, it's a developer problem. Ever been doing that forever. Like just shift it
Joel Moses
Sure.
Lori MacVittie
left, the developer should check. But maybe the developer did make an authorization call. Are they authorized? And the policy or some other mechanism on the back end is not correct. That it is actually allowing access at a broader level,
00:05:43:18 - 00:05:48:15
Lori MacVittie
right. Least privilege, I guess zero trust, is not being applied correctly there.
00:05:48:18 - 00:06:11:03
Joel Moses
Yeah. No, you're not going to get an argument from me. The developers bear a lot of the responsibility for this. I think where we may disagree slightly is, is to what the solution set actually occur, is here. Whether you can solve this using shift left mechanisms or whether you need to provide other security mechanisms. And what I'm going to say to that is, you're going to need both.
00:06:11:05 - 00:06:38:13
Joel Moses
Yes, you can count on shift less techniques to do this. Validation of authorization, the selection of of secure frameworks rather than trying to craft your own is a is a good step that a developer can take. So instead of trying to craft an authorization structure on their own, choose one of the popular authorization toolkits that are out there that have this built in and do those checks on every API, every API call.
00:06:38:15 - 00:06:59:17
Joel Moses
Now, you also want to protect yourself for when someone slips outside of those boundaries from the development perspective. So I also think you need other tools, like API gateway, or API security policy, or API security tools. And you need a good way to determine whether this condition is affecting you. But no, I, I think that the developer has a lot of responsibility here.
00:06:59:17 - 00:07:01:07
Joel Moses
And they must.
00:07:01:09 - 00:07:22:19
Lori MacVittie
I agree, they have they have responsibility. I just don't think the answer to everything, and it has been for a while, is just shift it left, just dump it on a developer. And that that obviously is not solving the problem. And you know what? Garland is an actual solution architect. So, solution architect which, you know, who is right? Are we both right?
00:07:22:19 - 00:07:28:07
Lori MacVittie
Are we both wrong? What's going on here? Right. How do you really, like, solve this problem so that it isn't a problem?
00:07:28:08 - 00:07:33:09
Garland Moore
Yea, so, I'm going to play it safe and say that you both are right.
00:07:33:11 - 00:07:35:11
Joel Moses
Yes.
00:07:35:13 - 00:07:36:01
Lori MacVittie
Ah, okay.
00:07:36:04 - 00:07:38:24
Joel Moses
Which a guest, the kind of guest we like.
00:07:38:26 - 00:07:59:27
Garland Moore
I think it, I think it's actually true. But Joel, to your point, right, when you talk about enforcing authorization, especially when it comes to APIs, you really need to be doing that at the object level. So if you think about, you know, APIs are everywhere, right? Mobile phones, apps, smart devices in your home, like all of these things are talking via APIs.
00:08:00:00 - 00:08:22:25
Garland Moore
So that's why it's so highly targeted, because it's a direct reference to objects, to where the data is, where the data lives.
Joel Moses
Right.
Garland Moore
So when you talk about enforcing authorization, it really needs to be done at an object level, right. So making sure that user 1-2-3, that user ID actually matches the object that they're trying to retrieve or that they're trying to make that get request to.
00:08:22:25 - 00:08:44:03
Garland Moore
So, that's usually one of the big things. I think you both said that in a, in a different fashion. But, and then also being able to centralize that authentication, right. Like these APIs are everywhere. So how do we control that and not have these one off or these ad hoc authorization logics built into the application. Right.
00:08:44:03 - 00:08:59:21
Garland Moore
We need to be able to centralize those. And then, you know, least privilege is not only common with APIs, but everything we do with technology. So,
Joel Moses
Right.
Garland Moore
how do we enforce the policy to only allow user 1-2-3 to be able to do what they're supposed to do?
00:08:59:23 - 00:09:29:28
Joel Moses
Right.
Lori MacVittie
Can we blame the the database? Cause ultimately
Garland Moore
Absolutely. Absolutely.
Lori MacVittie
Right? Okay. Hey, alright. Well, because, you know, we're talking about policies, but policies are just like, I mean, they're broader. They they never go down to Lori has only access to this account number. Right, it doesn't get that specific. So there's a some mechanism in the architecture that actually has to translate policy into, well, in the database this object is at,
00:09:29:29 - 00:09:54:02
Lori MacVittie
right. So there's there's something going on here too. And maybe we're missing that piece of it. Like we assume that developers can handle it in code or policy and, and gateways and external mechanisms can enforce it. And we're ignoring that databases really weren't built to like apply, right, I mean, value level, right? It
00:09:54:04 - 00:10:14:15
Joel Moses
Yeah.
Garland Moore
Yeah. Yeah.
Joel Moses
So here's where I go back and say that this all happens as part of the developer convenience loop, is what I tend to call it. Yeah, it's absolutely true that you put in a particular line or a field in a database, and the field belongs to a particular user. It really should only be given to that particular user account.
00:10:14:18 - 00:10:39:03
Joel Moses
But we, we, because of the way technology has just grown and matured, we usually break that linkage from the application to the database by by choice, because it's easier. So we log in from an application to a database using a service account. And that service account has no relationship with the data object that's being requested by the application.
00:10:39:03 - 00:11:03:09
Joel Moses
It's just an open access to the database. And then the developer is supposed to be the person ensuring that only the right fields make it from the database back through the application to the end user. So it's on the it's on the user, it's on the developer to to do that authorization step. I'm of the opinion that we need to kind of get away from using service accounts for data access.
00:11:03:09 - 00:11:23:06
Joel Moses
I think that the time has come,
Garland Moore
Yeah. Yeah.
Joel Moses
especially in the era of zero trust, that we need to pass authorization requests all the way back to the database and field and object level, and, and stop using service accounts for things. I think that the level of difficulty that represents for the developer is really high.
00:11:23:09 - 00:11:33:26
Joel Moses
But the payback is, is instantaneous. You don't you don't get, you don't risk things like BOLA attacks if you authorize all the way down to the data resource.
00:11:33:28 - 00:11:59:15
Garland Moore
And Joel, to that point, right, I think there are also things, so it is a little tougher, right, if you try to shift that left. But, there is some things you can do, right. You can integrate things like API scanners into CI/CD processes. But I do also agree, I was working on a project where the admin wanted to use a service account to retrieve and validate users password, and I'm like, oh my God, no we can't.
00:11:59:15 - 00:12:12:29
Garland Moore
Absolutely not. We will absolutely not do that, right. But it it's it's easy and it gets them over the hump to getting things functional. But that's when we have issues like BOLA become present. So,
00:12:13:00 - 00:12:49:27
Joel Moses
Yeah. Now I should also, I should also point out that it, you know, this sounds like a problem that might just affect an inexperienced developer developing a lightweight application and they just miss a step. But BOLA attacks have actually been factors in data loss for very prominent public applications and websites in the past. In 2019, Instagram had a BOLA situation where tweaking user IDs in API calls allowed access to private photos in other accounts that the user should not have had access to.
00:12:50:00 - 00:13:17:01
Joel Moses
That is a classical BOLA situation. And, and it led to a pretty serious black eye on, on the part of that, that, that site. In 2021, Parler, one of the social networks, they used numeric post IDs that they incremented one by one and they failed to check authorization. And so it was very easy to step from public article to a public article to several private ones, and just read everyone else's mail.
00:13:17:03 - 00:13:24:13
Joel Moses
And so, so things like this do happen, and they happen even in the larger development shops. I think it's important to realize that.
00:13:24:16 - 00:13:46:12
Lori MacVittie
I'd love to I'd love to, to put this off on, well, if people weren't bad and tried to do this in the first place, right, we wouldn't have to have these protections. Right. But but we do because people do that. Either they're curious or they're malicious, but people are going to do this. And now we're adding AI and agents.
00:13:46:12 - 00:14:08:11
Lori MacVittie
And there's been a lot of talk about non-human identity and such, but not a lot about this auth authorization side. And it's going to, like, be multiplied when you put a whole bunch of agents out there, because now you have not only my identity on behalf of, but their identity and then. Right, so how do you deal with that?
00:14:08:13 - 00:14:12:25
Lori MacVittie
You know, any suggestions? Garland? What do you think?
00:14:12:27 - 00:14:38:23
Garland Moore
Yeah. So I think, so you brought up a good point. I wanted to touch here. Like the, it's so easy to be bad these days, right? Like, I don't have to try hard to be bad, right? I can I can scour the internet, download some software, and off I go, right. So to that point, I think one thing, and Joel, you touched on this as well, is relying on URL format,
00:14:38:23 - 00:14:58:27
Garland Moore
right. So V1. Oh, now I retired v1, now I'm going to v2. So I just changed the URL v2. Well that's not really a form of security, right? Those those scanners that I can that I can get, you know, they're going to scan all of those common URL patterns that just get changed with those old API endpoints out there.
00:14:58:27 - 00:15:16:19
Garland Moore
So, to that point, one of those things is when you develop new APIs or different endpoints, then the old ones needs to be decommissioned or retired. I think we see a lot of those things hanging out there over time, and just because we change the URL doesn't mean it doesn't still exist, but then we kind of ignore that endpoint,
00:15:16:19 - 00:15:21:18
Garland Moore
and that's where the vulnerabilities happen.
00:15:21:20 - 00:15:40:20
Joel Moses
Right. Yeah. I can think of a few different solutions potentially for this, but I will be perfectly frank, Lori, a lot of them relate to the developer getting involved and being aware. And I know, I know that that is that is a painful thing for you to hear. And it is kind of a painful thing for me to say as someone who's developed software, but
00:15:40:20 - 00:15:43:25
Lori MacVittie
It didn't sound that painful.
00:15:43:27 - 00:16:00:03
Joel Moses
Yeah. I mean the developer, the developer has to has to be trained. They have to be trained better. They have to recognize that if I'm passing an object, before I pass that object the first thing that I should do is I should check to see whether there is an authorization to pass that object.
Lori MacVittie
Yes.
Joel Moses
It seems like extra work, but it's not.
00:16:00:03 - 00:16:23:03
Joel Moses
It's not extra work. It's actually adhering to a basic level of authorization control. I think in order to assist the developer, what they need to do is look for secure frameworks that have this secondary authorization check built in. I'm a particular fan of something called Open Policy Agent where the, the, the authorization step is actually externalized from the application
00:16:23:03 - 00:16:46:05
Joel Moses
and so you can write and change authorization checks on objects dynamically. I think those those technologies are incredibly powerful. And those frameworks are fairly easy to use and consume by developers because they don't require a lot of extra work. I think in terms of training developers, one thing we need to tell developers to do is stop using guessable object IDs.
00:16:46:12 - 00:16:47:22
Lori MacVittie
Okay, yeah, yeah, yeah.
Garland Moore
Yeah, yeah.
00:16:47:23 - 00:17:10:07
Joel Moses
If you are, if you are creating an object ID and you are simply incrementing by one every time you create a new one, you have created a predictable sequence. And an attackers, an attacker loves a predictable sequence because they just step up by one and maybe there's new data there. So so don't do that. Use use things like, like like generated
00:17:10:09 - 00:17:40:06
Joel Moses
UUIDs. Right. That have an element of, I won't say randomness, but, but pseudo randomness.
Lori MacVittie
At least.
Joel Moses
I'm sensitive to the mathematics here.
Lori MacVittie
Yeah, kay.
Joel Moses
But but those are not inherently guessable and, and have a, have a mechanism for, for providing a little bit of security through obscurity. And, and like Garland said, test. Develop tests. Test for this. Test for authorization failures within your pipeline.
00:17:40:08 - 00:17:51:03
Joel Moses
As you are shifting left put put the, put the test for these, these problems in your pipeline. But yeah, those are the some of the things that I can think of that are effective.
00:17:51:06 - 00:18:12:04
Garland Moore
Yeah, Joel, I was going to mention OPA. I like OPA a lot, especially when you talk about, you know, we hear a lot about infrastructure as code. OPA, more policy as code. And then you also talked about randomizing, you know, object IDs, which I think is key, right. Because a lot of those free tools that make it easy for me to be bad, you know, they just increment until they find something,
00:18:12:04 - 00:18:36:08
Garland Moore
right?
Joel Moses
That's right.
Garland Moore
But I think another use case is to add contextual checks just beyond user ID, right? So you've got the role of the user, tenant IDs, and ownership, right, through like JWT tokens, right. So, validating JWT claims can also help enforce, you know, isolation within the authorization flow.
00:18:36:10 - 00:19:08:06
Joel Moses
Now as you're building applications, I also think that it's not it's not enough just to to count on the developer to provide all of your security solutions for these API type attacks. You need to layer things. You need a layered defense. And so investing in things like a competently executed API gateway, perhaps one that has OPA support, that, that, that is that is something that that would provide significant value. Investing in, in secondary or red teaming or vulnerability testing tools
00:19:08:09 - 00:19:40:06
Joel Moses
is another one. Investing in a well executed web application firewall is another way to to prevent you from, from being susceptible to these attacks. But over overarching all of this is, you know, there's a principle in security called least privilege and least privilege is not about authentication at all; it's about authorization. And, and if you design everything for the principle of least privilege, you're always doing auth authentication, but you're always doing authorization steps as well.
00:19:40:06 - 00:19:55:16
Joel Moses
And thinking about the possibilities for least privilege holistically, doing things external to the application and doing things inside of the application according to that principle are going to protect you from BOLA attacks every day of the week.
00:19:55:18 - 00:20:11:28
Lori MacVittie
Garland, do you do you agree with all that advice? If we're, we're running up against time, so if you were to leave listeners with three things they could do to keep from being exploited by BOLA, what would you,
00:20:12:01 - 00:20:12:23
Garland Moore
Yeah, yeah absolutely.
00:20:12:25 - 00:20:13:29
Lori MacVittie
what would you tell them?
00:20:14:02 - 00:20:32:03
Garland Moore
So I do agree with all those things. And I think also one thing we have to mention here is the reason some of this happens is because we got to get the product out the door, right. So we're trying to get it done as quickly as possible to get to the end user whatever the app is we're delivering.
00:20:32:03 - 00:20:53:24
Garland Moore
But I think we need to take just a tiny step back and think about these things before shipping it out the door. So first thing I would say is just slow down a tad bit, right, and let's think about some of these things. I do like OPA, open policy agent that Joel mentioned, right. I think that's kind of an underutilized concept.
00:20:53:24 - 00:21:19:15
Garland Moore
There's some other frameworks out there that can that can implement that, but it also can help you go faster, right, if you have a policy as code engine. I like the idea of not incrementing the, the UUIDs, right. You know, randomizing those. And then also validating access, right. Validating access not just based on user ID, but the role and the ownership in in validating JWT claims.
00:21:19:17 - 00:21:39:14
Lori MacVittie
Awesome, awesome. So what I'm hearing is security is everybody's responsibility. And we all have a part to play, even developers. And so we all need to be pay more attention in order to get BOLA, you know, at least out of the top spot on the, the threat list or, you know, out of the top ten if we can.
00:21:39:14 - 00:21:53:05
Lori MacVittie
So let's,
Joel Moses
Right.
Lori MacVittie
let's all work toward that. But for now, that's, that's all we have time for today. So that's a wrap. If you survived this deep dive hey subscribe. You'll need the practice for the next outage.