Application programming interfaces (APIs) are taking over the internet. APIs now make up 83% of internet traffic because they help applications communicate with each other via API calls. And they’re a critical threat vector for companies. Corey Ball, author of “Hacking APIs,” saw the API takeover happening and realized there was a gap in security training and tactics. He founded APIsec University, which offers online courses to help level up the infosec community’s API security testing skills. APIs are essentially direct links to a company’s database, a valuable target for a malicious actor, and their flaws can be difficult to detect without proper documentation and thorough analysis. Security teams are just getting started tackling API security and Corey outlines how they can get started and which executives, including the board of directors, need to be aware of their API attack surface.
Application programming interfaces (APIs) are taking over the internet. APIs now make up 83% of internet traffic because they help applications communicate with each other via API calls. And they’re a critical threat vector for companies. Corey Ball, author of “Hacking APIs,” saw the API takeover happening and realized there was a gap in security training and tactics.
He founded APIsec University, which offers online courses to help level up the infosec community’s API security testing skills. APIs are essentially direct links to a company’s database, a valuable target for a malicious actor, and their flaws can be difficult to detect without proper documentation and thorough analysis.
Security teams are just getting started tackling API security and Corey outlines how they can get started and which executives, including the board of directors, need to be aware of their API attack surface.
----------
Listen to learn more about:
* His favorite API vulnerability
* Why generic security scanners can’t detect API security flaws
* The future of API security
Blake Sobczak: [00:00:00] Well, thank you so much for joining us, Corey. Really excited to dive into, uh, API security here, or Appi security. I don't even know. How do we, how do we pronounce it? First of all, for the Unin uninitiated listeners here.
Corey Ball: Yeah. Typically I go with API unless I'm using it in some fun way, like Happy Hacker, or Happy Hacking, or Happy, happy Sack Apsec. Yeah.
Blake Sobczak: Got it. Got it. Okay. Yeah. See for me, being based in Washington DC API means like the American Petroleum Institute lobbying group. So, uh, full disclosure, I'm not a technical, uh, guru here, so I will be, uh, leaning on your expertise for some of the nitty gritty aspects of API security. But I would be curious just to hear, you know, what the heck is an API and, and, and what goes into securing one.
Corey Ball: Yeah. An API is, uh, stands for Application Programming Interface, which really doesn't help anyone understand what they are, uh, any more than API does. But what it is is a common way for applications to communicate with each [00:01:00] other, and so through. A, um, through http requests, applications can make calls to other apps retrieve data and, uh, functionality from other applications.
Blake Sobczak: So it's like a, it's like a conduit almost for. Enhancing communication between different things or am I understanding that
Corey Ball: I. I, I like to use a restaurant metaphor to really understand, uh, what an API is and does. And if we think of a restaurant, you go into a restaurant, uh, you sit down at a table and you don't know how the dish is necessarily constructed by the chef. And everyone that's in that restaurant needs some.
Form of common communication to be able to tell the chef what they want. And so, uh, the way of doing that is by a waiter, which really functions as an api. You, you talk to the waiter, you look at the menu, you give the waiter the name [00:02:00] of the dish that you're looking for, without knowing how it's constructed or made or anything like that.
The waiter goes back to the chef. They use that, uh, those same instructions in order to order you. The dish. The chef construction constructs that with, uh, their knowledge of how to make the dish, and they give it back to the waiter. The waiter brings that dish over to you. And really that's how an API works.
Uh, a developer may be looking to borrow from the functionality of Google Maps or something like that. They don't have to understand how to. Design or program, uh, modern day gps and maps and create their own, uh, map. What they could do is they could leverage the, um, specialty that Google's providing through Google Maps, and they just need to know how to request that, which is normally done through API documentation.
And then once they make a proper request, they'll get back the data they're looking for.
Blake Sobczak: Gotcha. So in that metaphor, the waiter is almost like that api. You go to Google, you say, [00:03:00] I, I'm talking to this api. I want to get all this complicated gps, super fanciful stuff that Google's done all the hard work of creating, and then back in the kitchen, they serve that up to you. That's, I, I like that metaphor, and I, I, I guess that's apt as well because I'm, I'm guessing, I suppose I use APIs every day without even really realizing it or thinking about it.
Corey Ball: Yeah. Anyone that, uh, is using web applications or hosting them, Uh, very high probability it would be very challenging for someone to get on the internet and not, uh, use an api. The thing is that all the requests are taking place in the background beyond what you see in the graphical user interface of the browser.
And so a lot of people are not aware, uh, of all the traffic that's going on with the API in the background.
Blake Sobczak: So to continue the restaurant metaphor, have, have you seen the, the menu, the, the movie, the
Corey Ball: Yes, yes. That's a great movie.
Blake Sobczak: Uh, okay. It's a great movie. No spoilers, but let's just say, you know, what happens if something with API security goes wrong in the process of, uh, going to a restaurant? Uh, I [00:04:00] don't think that's a spoiler to say that the menu is a little bit, uh, something's a little off there.
Corey Ball: Yeah. It might be a spoiler to say the conclusion, the conclusion of that movie might happen now, but when, when things go wrong with APIs, when they're insecure. The problem is, uh, they're a direct pipeline to the most valuable resources that criminals are often looking for, which is a company's data.
And so APIs get you direct access to that. So if, uh, there aren't the proper security controls in place, anyone on the internet that has access to that api. Would be able to leverage those API requests to retrieve, uh, the data that organizations are often trying to protect the most.
Blake Sobczak: Yeah, that doesn't sound good. And, and if you wanna prevent that from happening, I guess, what are some differences between testing a traditional web application versus specifically testing an API for security flaws?
Corey Ball: [00:05:00] Yeah. So before we get into the differences, the, the similarities between the two. Uh, when, when I talk about web app testing, a huge part of that, if not a majority of it, is actually API testing because web apps are so, Uh, they, they have APIs built into their fabric, and all portions of modern web apps, uh, involve APIs.
So for me, there's a lot of crossover and I'm, I'm hoping that it's not just for me, and that more and more people are on the same page with that. But the, the similarities, they're, they're both using a CTP requests. Um, typically web app testing involves the graphical interface that you see in the browser, and so you could be, uh, attempting to bypass authentication if that's a part of the browser, uh, and not an API request, cuz that could often be an API request itself.[00:06:00]
Um,
Blake Sobczak: Like a log, like a login prompt of like, I'm, I wanna log into my bank or something.
Corey Ball: Yeah, or any information that's gonna be in the HTML or, or presented, uh, with JavaScript, that's all gonna be on the web app side. Um, so APIs, like we've said up to this point, they're, they're not graphical. So these are just http requests that are going on in the background in a, in a common way.
And so the APIs are, um, stateless and so, Instead of having cookies in a web application, you're gonna have likely a token, some form of token that says, this is who I am and this is what I'm authorized to accept. And. In order to test APIs, you need to use browsers that are meant for API requests.
Something like Postman, or if you're intercepting a request with Burp Suite, uh, those are both good ways to [00:07:00] see the requests that are passing back and forth. And so, uh, with APIs being stateless, you're gonna test for authentication in slightly different ways. You're gonna want to see, you know, our tokens.
Built in a predictable way. Uh, are tokens even required? Are they using something like, uh, a JSON web token that has some misconfigurations or information disclosure involved? Uh, beyond that, the biggest issue with APIs is authorization, and so is my token. Uh, going to authorize me to only access my resources.
And so one of the tests you'll often do is, uh, have two user accounts. And can I use my token from user A to interact with user B'S resources? Uh, another big aspect, uh, in the differences, the tools that have classically worked for web apps. Don't work for APIs. They don't even [00:08:00] test for a lot of the API issues.
Uh, typically if we're thinking of something like the O OSP top 10, those, those tools are going to be testing for a lot of those. But if we're thinking of the O osp API security project and their top 10 list, uh, typically only one of those items is tested for, which is, uh, security misconfigurations and.
Everything else. Authorization testing, the authentication testing. Um, those typical tools that are used for web apps come back with no results, giving a false sense of security. So APIs do require a specific focus type of testing for a specific type of issue.
Blake Sobczak: Who's, who's building these APIs, right? I I, I almost feel like given how ubiquitous there, it seems, shouldn't they be a little more fundamentally secure? Like Google's, for instance, if they're serving that up to anybody trying to get something from Google Maps to tailor to their own needs, like, I feel like that would be pretty buttoned up, right?
Are, are these vulnerabilities really all that [00:09:00] common?
Corey Ball: Yeah, so I, I think I've heard a statistic recently that like 60%. Or more of developers, uh, spend some percentage of time something like 30% of their time, uh, developing and working with APIs. So this is prevalent, uh, across industries, whether you're talking about, um, FANG or or smaller apps with small dev teams.
Everyone's using APIs across the board
And so, you know, at a lot of the, uh, bigger incidents that involve those companies, they, they're in the news or, you know, they're gigantic, uh, bug bounty prizes for those, and, and you see some of those out. So even fang are, are not, you know, completely safe from those, uh, issues.
They're all over the place.
Blake Sobczak: Right. Well, speaking of news events, I, I did read something about a, uh, 2022 [00:10:00] Optus, uh, data breach that involved APIs. I, I guess what, stu, what struck you from that event? What stood out as interesting about that compared to other breaches?
Corey Ball: Yeah, so with Optus from, from the information that was released about it, The attacker found an endpoint that did not require authentication or authorization, and, uh, they were able to request private data using that endpoint. And so what they did is they started to collect all of that data, and oftentimes with attackers at that point, uh, once the criminal has all the data, they go and they sell it somewhere on the black market.
Um, in this case, the attacker. Got a lot of confidence and decided they're gonna go back to the source. And, uh, essentially ransom Optus saying, Hey, I have 10 million instances of private data from your [00:11:00] clients, and I want, I, I don't remember if it was a million dollars or 10 million or what it was, but essentially, I want to be paid that amount or else I'm going to release all of this data and just like, I don't know, a Hollywood ransom or something.
They started to release, uh, a small amount of data every hour or so to, to prove that they really had this, uh, data.
Blake Sobczak: And, and for, for listeners who may not be familiar with, with, uh, who Optus is, this is not some Spring chicken. This is a major Australia based telecommunications company with lots of customers, huge footprint across that region. And just, uh, it was not a fun time for those involved. And I guess there were some, it sounded like there were some drastic disagreements, right?
Between, between Optus CEO and some, uh, some of Australian cybersecurity officials.
Corey Ball: There were, and, and just to add to that, the Optus data breach is considered one of the worst data breaches in Australian history. So a pretty big deal there. [00:12:00] But there, there was, uh, a public internet exchange almost between the Australian cybersecurity minister and then a chief executive at Optus.
And essentially, Uh, the executive, uh, Optus was saying, you know, this was a very complicated attack. We have many layers of security in place. It would be very challenging for an attacker to come up and just steal all this data from us. Meanwhile, the Australian Cybersecurity minister out on Twitter and such, uh, is saying the opposite.
This is, Not a complicated attack. This is like leaving your front door wide open and being surprised that some, a thief went and stole everything. And so I, I think. Both are truthful in what they're saying. The Optus executive knows they have a budget dedicated to cybersecurity controls and they know that they have defense in depth and firewalls and all these things are probably putting a lot of money into and a lot of time into to defend [00:13:00] the, the problem is a lot of the classic tools, like I was saying, they, they don't test for a p i vulnerabilities.
Uh, that well. And so you, you may be scanning it, you may be using, uh, the arsenal that's been built for your cybersecurity program. Uh, but if you're using it on APIs without specific types of tools and techniques, it's gonna come back with, uh, false negative results. And it's going to give companies like Optus a false sense of security.
So there's a good chance that their vulnerability management program. Uh, and other tools were being used for these endpoints, but were any of them configured to make sure that authentication and authorization are required for all the requests that are. Uh, going on across their entire attack surface of APIs.
And so I think that side is, could be completely honest in their belief that, you know, we have many layers of security, so I can't imagine [00:14:00] how this would happen from a simple attack. Meanwhile, an exposed endpoint out to the internet that doesn't require authentication authorization, that consumes. Uh, or provides client data that is gonna get past all that stuff and just straight into the, uh, criminal's pocket.
Blake Sobczak: See, this is why I'm glad I'm not a CSO because it sounds like my excuse of, ah, I don't understand APIs. How could this happen? Isn't really gonna fly in the face of a major multimillion dollar data breach. Um, but it does seem like, you know, on, on the bright side, it does seem like more companies are starting to.
Pay attention to this and really including cac, I should say, prioritize API security, uh, as, uh, sort of an an offering or a specialty. Um, does this seem like a trend to you? And, and I guess what do you think prompted that shift?
Corey Ball: Yeah, I do think organizations are starting to catch on. I, I don't know the primary driver, but some of the things that drove me to, [00:15:00] um, really focus on APIs were a lot of the facts that are out there that were coming out between, uh, 2018 and, and current A. So you have things like 83% of all, all web traffic is API related.
And so when you're considering different things like. Uh, a web app or a network pen test or, or these other items. APIs are really at the center of the attack surface when that much web traffic is API related.
Blake Sobczak: That's, that's kind of shocking. I mean, can, can we just pause a second and unpack that stat a little bit more? 83% of web traffic, that's that we're talking like the web, the internet, the whole world. All of that's getting routed through APIs.
Corey Ball: Yeah. So, uh, as far as all, all web traffic across the internet, That is going to be a huge super majority of APIs that are causing that. And the reason is APIs were designed to be machine to machine communication [00:16:00] and all of that can run in the background. If, if you were to go to twitter.com and load up your profile page, so many API requests are going on in the background to load that page.
So you're gonna have requests that are focused on just, uh, Populating the text, populating the images, populating the videos, um, all that stuff is going to be powered by bunch of API requests going on in the background. So even though from your perspective, it's a single request to a single url, all of that, uh, takes place in the background.
And that's just going on at a huge scale across the internet. I mean, if you think of. All the companies that have sort of, uh, really taken advantage of APIs and exist primarily because of their functionality. Something like Uber, where back before web APIs are prevalent, you have to design your own maps, payment system, uh, communication, so on and so forth.
And now you could really take the specialty of these other [00:17:00] development teams that are monetizing and making, uh, a portion of their functionality public. So that now something like Uber could use Twilio for communications, they could use, uh, a payment processor that's out there and Google for maps, so on and so forth in order to build up this new business, uh, that really functions off of the specialties of other organizations.
So there's a big economic driver that's a part of it. And then a lot of the actual requests are just going on beyond the graphical user interface.
Blake Sobczak: So, so you touched on this a little bit, but I, I did wanna dive back into kind of the origin story of your interest in APIs. Like what, what really sparked your interest in when, like, how long have these things even been around?
Corey Ball: Yeah, so I see, uh, I, so somewhere around, you know, we, we could say 10 years to, to say that web APIs start to pick [00:18:00] up, it's just you start to see the adoption rate really increase from 2017 and on 2018 and on. And that's about the time that I started to get interested, essentially in late 2019. One of the partners at Moss Adams, uh, I was there doing web app pen testing primarily, and they said, Hey, you know, we're having a lot more clients reach out specifically for API penetration testing.
Can you be the subject matter expert on that? And I ran with it, and that's really what kicked off my interest. But what, what, uh, really enthralled me was the, the, some of the facts that we've already talked about. So like, I learned how prevalent APIs were in the economy, uh, for, for companies that are in e-commerce, FinTech, healthcare, manufacturing.
Really it's all over the place and. Uh, the creation of new organizations like Uber that are really powered off of connecting all these APIs [00:19:00] together. I, I found that really interesting.
Blake Sobczak: did you find a lot of the skillsets that you brought to the table carried over well to APIs, or was it like starting from scratch, learning a whole new skill?
Corey Ball: Yeah, there was a part of what I knew from web app testing that definitely carried over and you know, things like the Mitre kill chain and typically how I'd go about an attack from an outside the network and so on and so forth. Uh, but once you start getting in. To APIs, you start to, uh, go off on a branch from there.
So, uh, knowing how to intercept HTTP requests, understanding response codes, and how to form, uh, an HTTP request, those were all helpful things to start out, uh, in API testing.
Blake Sobczak: what do you think is most commonly. Misunderstood about API security given that it's still, you know, a relatively new space.
Corey Ball: Yeah, I think it's one of the things I've touched on already, which [00:20:00] there's a big problem, uh, when we're using these classic vulnerability management tools and expecting them to work with APIs. And so, uh, in a lot of the talks that I give, I'll bring up screenshots of what happens if you're just doing a generic ZAP scan or a Burp suite scan.
Any of the vulnerability scanners when you apply those to APIs, they don't detect anything because they don't have, uh, definitions in place to even check for a lot of the top findings that are associated with the OWA API security top 10. So, uh, when you're doing a generic scan of those, you're not getting beyond authentication requirements.
So you have to make sure that you are authenticating to the web app, uh, getting an authorization token to be able to use the api. Then, uh, whatever tool you're using needs to, uh, be able to make, um, authorized requests [00:21:00] to all of the endpoints that are involved with an api. So, Uh, what helps us is if an API is defined, if it has, um, uh, open API specs or something like that.
Those documents actually help the tools define, uh, all the endpoints and how the requests are made, and so, Uh, just applying those scanning tools generically and seeing no results come back. Looks like you're doing a really good job at protecting your APIs. Unfortunately, when you use those same tools against deliberately vulnerable applications and they come back clean, that's a sign that the tools are not working.
And so a lot of the. Uh, important findings that you wanna block, like authorization, uh, user A, being able to access user B's information. Those things are not tested from generic scans.
Blake Sobczak: That's a little frightening, especially when you think about compliance regimes. Have they caught up to this new reality of, I mean, can you just say, Hey, I ran some scans and it [00:22:00] all looks good, checklist, boom, done. No problem. And, and kind of emerge. Okay. I know obviously it varies from industry to industry, but have you seen that?
Are, are people keeping up with these.
Corey Ball: I hope so. Um, uh, no, we, we still see a lot of issues all over the place with APIs, so it's still very common, uh, to find issues. And yeah, we're starting to see organizations catch on, but a lot of those basic blocking and tackling type vulnerabilities are still, uh, getting beyond it. And I think a part of it is, you know, if you are using those tools, you're using a vulnerability scanner.
There are findings on the servers and you're remediating those. And so do you really know to dig deeper into that without penetration testing or a bug bounty program, uh, or some other almost independent third party that's coming in and really testing those things as they should be.[00:23:00]
Blake Sobczak: Right, because otherwise you're like, Hey, look, this is sh this is showing, we still have room for improvement. It, it must be working. We've got a couple things we can fix up, and oh, we actually never peaked under the hood at our APIs. Yeah, that's, that's a little eye-opening. And I, I, I would be curious, you know, if you can put on your, uh, prediction hat.
I know we all love predicting the future. Where, where do you see API security going? Do you think it's gonna get better, get worse, then get better? Somewhere in between? What's your forecast?
Corey Ball: Yeah, I feel like we still have to cross over, uh, the worst parts to, to get there, but it's pretty close. And not to say, you know, something horrible is around the corner, even though it probably is. Uh, but I, I do think those. Publicized incidents and bug bounty write-ups, uh, with large bounties really bring the focus on those incidents to other big organizations to help close those items out.
Um, I've, I've met with like all the API security vendors, uh, and demo [00:24:00] their products and I think, you know, they're starting to catch on too, that. API security is like enterprise security. It takes a layered approach. So there are different tools that function at different layers for API security, just as there are with general enterprise security.
So I think there's a lot of that catching onto, uh, that you know, you're gonna want. A tool or a technique in place to, to test as far left as possible in the development cycle. And then once, uh, your app is released, pre-production, you're scanning it, making sure there aren't any vulnerabilities with tools and techniques that are meant for APIs.
And then of course, you're on the other end, you're monitoring, uh, and, and logging any potential incidents and learning from those.
Blake Sobczak: Do you have like a favorite API security flaw, or, you know, wow, I can't believe I was just allowed to do that with this, through this api.
Corey Ball: Yeah. Um, definitely. I mean, for me, I, [00:25:00] I really like. Uh, pairing together vulnerabilities. So if I could find an outdated version of the api, uh, which is one of the top 10 findings. So improper inventory management, uh, is one of the new ones. And if, uh, an API is on version three and you go back and request version one and you're able to have, uh, Different functionality or access to different endpoints that you were not able to otherwise.
I like those. I like information disclosure vulnerabilities. If unnecessary headers are included, that will give you additional information about what's going on. Maybe the. Um, amount of time it takes for the server to process the request. That could help indicate, you know, additional processing power if you're finding true resources versus not, regardless of the http response code.
And then I'm all time favored though is like if you're, if you're dealing with, uh, FinTech API or banking API and you're able to. Uh, [00:26:00] use broken function level, authorization, vulnerability. So essentially there aren't authorization blocks in place to prevent me from transferring money from another person's account into my account.
I, you can't beat that.
Blake Sobczak: I can see why that's, I can see why that's your favorite. We don't need to dive deeper into why that's your favorite, just in case. Just in case we have any b i folks listening. Just kidding. Um, but, uh, no, that, that's, that's really fascinating. And, um, I, I know that, you know, having its own o OSP top 10 just for APIs, I think speaks to the level of. uh, specialty involved here and, and, and that it's, it is a different animal. And to that end, I'd be curious to hear more. Tell me more about this. Uh, this book of yours, you have, uh, hacking APIs. Is that right?
Corey Ball: Yep, that's right. So I wrote Hacking APIs. I started back in December, 2019. I took 150 pages of, uh, notes in my research and I was like, Hey, I'm halfway to a book. You know, I [00:27:00] wonder if any publishers would be interested. I went to one of my favorite publishers, no Starch Press, uh, and ended up teaming up with them.
Which was an awesome process. Uh, from there I wrote for a good 16 months after hours on the weekends doing research and writing and putting it all together. And then about eight months of editing and editing and editing.
Blake Sobczak: Oh bye.
Corey Ball: And, uh, once, once all that was finished, then uh, the book, uh, was released uh, July last year in retail stores, which was awesome.
Uh, then in December of last year, I actually won book of the year with, uh, sands, uh, difference Maker Award. So that was pretty cool. And yeah, the book, it takes you from zero to Hero. So if you really don't know much about web apps or APIs, I include introductory information on the technology. Uh, HTP response codes, how [00:28:00] to form an HTTP request, getting into the top vulnerabilities that affect APIs with, uh, you know, os top 10 included, but beyond that as well.
And then, uh, from there, I wanted, you know, the, the books that helped me the most were. The ones that have hands on labs. And so that was very important to me to include in there. Uh, and there's two different, I feel like there's two different, uh, ways of doing labs and books. One is, here's the problem, good luck.
You know, go, uh, go try really hard and see if you can solve it. I'm not too big of a fan of those, especially when you're learning a new thing. Uh, the other ways, what I did, which is more of a side by side lab. So here's the issue, here's the thought process. Uh, here's my approach. And, you know, I want you to follow along with your fingers on the keyboard while we're doing this.
Like you're typing in the same commands, you're finding similar things. Now go beyond and solve this extra problem. So that's, uh, that's how I [00:29:00] developed the labs in there. And after that came out, I wanted to create a free educational course that anyone can have access to that gets them the basics of. Uh, penetration testing api.
So that's what I released over at Apsec University and for, for me, you know, once you know how many that 83%, uh, and beyond of web traffic is API related, once you know that there are tens of millions of endpoints and API requests going on, You know that, uh, as an industry of testers and breakers we're probably a few steps behind.
So getting out that information and arming the testers, uh, as effectively as possible is really important in helping, you know, bug bounty hunters learn to test thoroughly, um, for these vulnerabilities, I thought was very important to you. And so just getting that information out there, um, for [00:30:00] everyone to be able to get their hands on the keyboard.
And really there's nothing. I designed the course so that there's little to nothing to purchase. You have to have, uh, a system that you can access. You need to have a keyboard to be able to type in the commands, but the tools and everything else that's in there, I made sure everything was free. And so you can just get on a computer, set up your machine, and start testing APIs.
Blake Sobczak: That's really cool. Is there gonna be a, is there gonna be a sequel hacking more APIs, sql not, not meaning the sql. Um.
Corey Ball: Yeah, yeah, yeah. So, um, for the API pen test course, really that, um, was a more advanced course. Like I said, sort of, uh, having people dive straight into the hands on testing. So I think it, it's important to go back and cover some of the basics. So we just released. An API security fundamentals course, which is a high level API security course to get some idea, uh, in the, uh, of API security.
And [00:31:00] that one's approachable, you know, from the analyst to the C-suite, uh, high level security information that involves APIs. Um, I do want another course that's gonna focus on the top vulnerabilities, really diving into each of those. Uh, thoroughly. And then, uh, a basics course that if you're not familiar with web app testing at all, maybe you're not familiar with penetration testing at all, that you could take that course, get an understanding of HDP requests, the basics, the methods, uh, response codes, and dive into api, uh, testing from there.
So I think that's, yeah, tho those things are definitely in the works for, uh, additional free courses.
Blake Sobczak: Stay tuned. Well, it, it is interesting to hear, obviously all of these resources are incredibly valuable for people active in the penetration testing community who are gonna be looking for these flaws. Stepping back a second, do you feel like who needs to know about APIs? Like, do, do, do board members need to know like what an API is?
[00:32:00] Do CEOs, like, how big of an audience, uh, does this deserve at this point?
Corey Ball: Yeah, I mean, the CSO CTO should definitely be aware of their API attack surface. So what third party APIs do they depend on? Wh which ones are they consuming? What are they providing and are those protected? So I think all of that is extremely important to, to grasp, uh, CEO and above. Like how, how much does the business rely on APIs and what is the, the risk there?
So, uh, are resources being dedicated to make sure that those are tested properly and that findings are remediated over a quick amount of time. Um, is there a bug bounty program where APIs are, uh, right in the spotlight for that? Uh, I think some of those things are, are important to know at a high level.
Blake Sobczak: Well, this has been a really illuminating [00:33:00] discussion. Appreciate you sharing some of your, uh, expertise here with our listeners. And we have, uh, I do have one more question for you, which is something we ask all of our guests, uh, and that's something we wouldn't know about you just by looking at your LinkedIn profile.
Corey Ball: Gotcha. Yeah. So let's see. I have three daughters. They're all in elementary school. Um, love spending time with them and raising them. I'm. In southern Oregon out of a small town called Grants Pass. So it's actually, I, I'm in a rural area. I'm, I'm on an acre in a rural area, but I happen to have like gigabit internet, so it's the best of both worlds
Blake Sobczak: Jealous.
Corey Ball: of that.
Yeah, right. I haven't experienced traffic in a couple years, so that's pretty nice.
Blake Sobczak: Listen, I'm based in DC so motorcades and oh my God. Yeah, traffic is not fun here.
Corey Ball: Um, outside of that I'm a pretty big board, board game nerd and collector, and so I, I play a lot of board games [00:34:00] and, uh, like getting my hands on new ones.
Blake Sobczak: Oh, nice. Well, um, uh, I don't, don't, don't tap me for your Arcam horror group game. I just, I can't handle it. It's, it's too much. Uh, but I'll, I'll give it the old college try. But that, that's really, that's really interesting. And, uh, maybe in DC Scrabble, I can do the simpler ones, you know? All right. Thanks Corey, uh, for joining us.
Really, really insightful stuff.
Corey Ball: Thanks so much for having me on.