Meet the experts who power Synack’s strategic security testing platform. Our Synack Red Team unites over 1,500 of the world’s most skilled and trusted security researchers, who work with patented technology to deliver best-in-class offensive security testing on a continuous basis.
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 beginning to understand how to 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
Listen to the episode
S2 E10 · API security decoded with Corey BallWE'RE IN! Podcast · 35 min
Key takeaways
Generic scanners miss most API flaws Corey says tools like ZAP, Burp Suite scans, and Nessus typically only catch security misconfiguration from the OWASP API Security Top 10, and return clean results that give a false sense of security.
Authorization is the biggest API issue A core test is using user A's token to reach user B's resources. Generic scans do not check this.
One exposed endpoint can bypass defense in depth In the Optus breach, an internet-facing endpoint required no authentication or authorization, letting the attacker collect customer data despite the company's other security layers.
Give tools API documentation Scanners need authenticated access and definitions such as OpenAPI specs to reach every endpoint. Testing them against deliberately vulnerable apps shows whether they actually work.
Leaders should know their API attack surface CISOs and CTOs should know which third-party APIs they consume and provide and whether those are protected; executives should know how much the business relies on APIs.
Topics covered
API Security
Notable quotes
…when things go wrong with APIs, when they're insecure, the problem is they're a direct pipeline to the most valuable resources that criminals are often looking for, which is a company's data.
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.
…API security is like enterprise security. It takes a layered approach…
…we know that as an industry of testers and breakers, we're probably a few steps behind.
Questions this episode answers
What is an API in simple terms?
Corey compares an API to a waiter in a restaurant: you order from the menu without knowing how the chef makes the dish, and the waiter brings it back. Developers request functionality like Google Maps through documented API calls the same way. Read this section
How is API penetration testing different from web app testing?
APIs are stateless and use tokens instead of cookies, so testers check how tokens are built and whether they are required. The biggest focus is authorization, and classic web app scanners do not test for most API issues. Read this section
What happened in the 2022 Optus data breach?
Based on released information, an attacker found an endpoint that required no authentication or authorization, pulled about 10 million records of private data, and tried to ransom Optus by releasing data in batches. Read this section
Why do vulnerability scanners fail on APIs?
They lack definitions for most OWASP API Security Top 10 findings and often do not get past authentication, so they return no results even against deliberately vulnerable applications. Read this section
Who in an organization needs to understand API security?
Corey said CISOs and CTOs should know their full API attack surface, and the CEO and above should understand how much the business relies on APIs and whether resources go to testing and remediation. Read this section
About the guest
Corey Ball is, at the time of recording, senior manager of penetration testing at consulting firm Moss Adams and chief hacking officer at APIsec University, which offers free online API security courses. He is the author of Hacking APIs, published by No Starch Press, which he said won book of the year in the SANS Difference Maker Awards. He began specializing in API penetration testing in late 2019 after doing primarily web app testing.
Hello, and welcome to WE'RE IN, a podcast that gets inside the brightest minds in cybersecurity. I'm your host, Blake Sobczak, and I'm joined today by Corey Ball, Senior Manager of Penetration Testing at Consulting Firm, Moss Adams, and Chief Hacking Officer at APIsec University, which is a fantastic resource for anyone interested in the ins and outs of API Security. And if you have no idea what an API is or why you should care, just bear with me for a second as we'll get to that with Corey. Suffice it to say that API calls make up the vast majority of web traffic right now, so you really should be paying attention. But before we dive into all things APIs with Corey, let's hear a quick word from our sponsor.
Traditional penetration testing needs an overhaul. Get smarter about your security posture with an adversarial security testing platform that surfaces vulnerability trends and identifies root causes to thwart attackers at every turn. Learn more at synack.com. That's synack.com.
Well, you so much for joining us, Corey. Really excited to dive into API Security here, or API Security. I don't even know... How do we pronounce it, first of all, for the uninitiated listeners here?
Got it. Got it. Okay. Yeah. See, for me, being based Washington DC, API means like the American Petroleum Institute lobbying group. So full disclosure, I'm not a technical guru here, so I will be 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?
Yeah. An API is... It stands for application programming interface, which really doesn't help anyone understand what they are any more than API does. But what it is is a common way for applications to communicate with each other. And so through HTTP requests, applications can make calls to other apps, retrieve data, and functionality from other applications.
I like to use a restaurant metaphor to really understand what an API is and does. And if we think of a restaurant, you go into a restaurant, 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 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 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... Those same instructions in order to order you the dish. The chef constructs that with 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. 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 modern day GPS and maps and create their own map. What they could do is they could leverage the specialty that Google is 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.
Gotcha. So in that metaphor, the waiter is almost like that API. You go to Google, you say, I'm talking to this API, I wanna 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. I like that metaphor. I guess that's apt as well because I'm guessing, I suppose I use APIs every day without even really realizing it or thinking about it.
Yeah, anyone that is using web applications or hosting them, very high probability. It would be very challenging for someone to get on the Internet and not 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 of all the traffic that's going on with the API in the background.
Oh, 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 going to a restaurant? I don't think that's a spoiler to say that the menu is a little bit... Something's a little off there.
Yeah. It might be a spoiler to say the conclusion the conclusion of that movie might happen. No, but when things go wrong with APIs, when they're insecure, the problem is 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 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 the data that organizations are often trying to protect the most.
Yeah. That doesn't sound good. 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?
Yeah. So before we get into the differences, the similarities between the two, 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... They have APIs built into their fabric and all portions of modern web apps 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 HTTP requests. Typically, web app testing involves the graphical interface that you see in the browser. And so you could be attempting to bypass authentication if that's a part of the browser and not an API request, because that could often be an API request itself.
Or any information that's gonna be in the HTML or or presented with JavaScript, that's all gonna be on the web app side. So APIs, like we've said up to this point, they're not graphical. So these are just HTTP requests that are going on in the background in a common way. And so the APIs are stateless. And so instead of having cookies in web application, you're going to 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, those are both good ways to see the requests that are passing back and forth.
And so with APIs being stateless, you're going to test for authentication in slightly different ways. You're going want to see, are tokens built in a predictable way? Are tokens even required? Are they using something like a JSON web token that has some misconfigurations or information disclosure involved? Beyond that, the biggest issue with APIs is authorization. And so is my token going to authorize me to only access my resources? And so one of the tests you'll often do is have two user accounts. And can I use my token from user A to interact with user B's resources? Another big aspect in the differences, the tools that have classically worked for web apps don't work for APIs.
They don't even test for a lot of the API issues. Typically, if we're thinking of something like the OWASP top 10, those those tools are going to be testing for a lot of those. But if we're thinking of the OWASP API Security Project in their top 10 list, typically, only one of those items is tested for, which is security misconfigurations. And everything else, authorization testing, the authentication testing, 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.
Who's building these APIs? I almost feel like given how ubiquitous they are, 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, I feel like that would be pretty buttoned up. Right? Are these vulnerabilities really all that common?
Yeah. So I think I've heard a statistic recently that 60% or more of developers spend some percentage of time, something like 30% of their time developing and working with APIs. So this is prevalent across industries, whether you're talking about FAANG or smaller apps with small dev teams, everyone's using APIs across the board. And so, you know, at a lot of the bigger incidents that involve those companies, they're in the news or, you know, they're gigantic bug bounty prizes for those and you see some of those out. So even FAANG are not, you know, safe from those issues. They're all over the place.
Right. Well, speaking of news events, I did read something about a 2022 Optus data breach that involved APIs. I guess, what struck you from that event? What stood out as interesting about that compared to other breaches?
Yeah, so with Optus, from the information that was released about it, the attacker found an endpoint that did not require authentication or authorization, and 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, once the criminal has all the data, they go and they sell it somewhere on the black market. In this case, the attacker got a lot of confidence and decided they're gonna go back to the source and essentially ransom Optus saying, hey. I have 10,000,000 instances of private data from your clients, and I want... I I don't remember if it was a million dollars or $10,000,000 what it was, but essentially, I wanna be paid that amount or else I'm going to release all of this data.
Just like, I don't know, a a Hollywood ransom or something, they started to release a small amount of data every hour or so to prove that they really had this data.
And for listeners who may not be familiar with 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... 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 some of Australian cybersecurity officials.
There were. 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 But deal there was a public internet exchange almost between the Australian cybersecurity minister and then a chief executive at Optus. And essentially, the executive at Optus was saying, 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 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 a thief went in 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. The problem is a lot of the classic tools, like I was saying, they don't test for API vulnerabilities that well. And so you may be scanning it, you may be using the arsenal that's been built for your cybersecurity program, but if you're using it on APIs without specific types of tools and techniques, it's going to come back with 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 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 going on across their entire attack surface of APIs.
And so I think that side could be completely honest in their belief that, you know, we have many layers of security, so I can't imagine how this would happen from a simple attack. Meanwhile, an exposed endpoint out to the internet that doesn't require authentication authorization that consumes or provides client data, that is gonna get past all that stuff and just straight into the criminal's pocket.
See, this is why I'm glad I'm not a CISO 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. 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... And including Synack, I should say, prioritize API security as sort of an an offering or a specialty. Does this seem like a trend to you? I guess, what do you think prompted that shift?
Yeah, I do think organizations are starting to catch on. I don't know the primary driver, but some of the things that drove me to really focus on APIs were a lot of the facts that are out there that were coming out between 2018 and current day. So you have things like 83% of all web traffic is API related. So when you're considering different things like a web app or a network pen test or these other items, APIs are really at the center of the attack surface when that much web traffic is API related.
That's kind of shocking. I mean, can we just pause a second and unpack that stat a little bit more? 83% of web traffic, we're talking like the web, the internet, the whole world, all of that's getting routed through APIs?
Yeah. So as far as all web traffic across the internet, that is going to be a huge super majority of APIs that are causing that. The reason is APIs were designed to be machine to machine communication, 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 going to have requests that are focused on just populating the text, populating the images, populating the videos. 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 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 really taken advantage of APIs and exists primarily because of their functionality, something like Uber, where back before web APIs are prevalent, you have to design your own maps, payment system, communication, so on and so forth.
And now you could really take the specialty of these other development teams that are monetizing and making a portion of their functionality public so that now something like Uber could use Twilio for communications. They could use a payment processor that's out there and Google for maps, so on and so forth in order to build up this new business that really functions off of the specialties of other organizations. So there's a big economic driver that's a part of it. Then a lot of the actual requests are just going on beyond the graphical user interface.
You've touched on this a little bit, but I did want to dive back into the origin story of your interest in APIs. What really sparked your interest and when? How long have these things even been around?
Yeah. Somewhere around, we could say ten years to say that web APIs start to pick up. It's just you start to see the adoption rate really increase from 2017 and on, 2018 and on. That's about the time that I started to get interested essentially in late twenty nineteen. One of the partners at Moss Adams, I was there doing web app pentesting primarily, 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 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 for companies that are in ecommerce, fintech, health manufacturing.
Really, it's all over the place. And the creation of new organizations like Uber that are really powered off of connecting all these APIs together, I found that really interesting.
Did you find a lot of the skill sets that you brought to the table carried over well to APIs or was it like starting from scratch learning a whole new skill?
Yeah, there was a part of what I knew from web app testing that definitely carried over and things like MITRE kill chain and typically how I'd go about an attack from outside the network and so on and so forth. But once you start getting in to APIs, you start to go off on a branch from there. Knowing how to intercept HTTP requests, understanding response codes and how to form an HTTP request, those were all helpful things to start out in API testing.
Yeah. I think it's one of the things I've touched on already, there's a big problem when we're using these classic vulnerability management tools and expecting them to work with APIs. And so 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, Nessus, any of the vulnerability scanners. When you apply those to APIs, they don't detect anything because they don't have definitions in place to even check for a lot of the top findings that are associated with the OWASP API Security Top 10. So when you're doing a generic scan of those, you're not getting beyond authentication requirements. So you have to make sure that you're authenticating to the web app, getting an authorization token to be able to use the API.
Then whatever tool you're using needs to be able to make authorized requests to all of the endpoints that are involved with an API. So what helps us is if an API is defined, if it has OpenAPI specs or something like that, those documents actually help the tools define all the endpoints and how the requests are made. And so 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 important findings that you wanna block, like authorization, user A being able to access user B's information, those things are not tested from generic scans.
That's a little frightening, especially when you think about compliance regimes. Have they caught up to this new reality? Can you just say, Hey, I ran some scans and it all looks good, checklist, boom, done, no problem, and emerge okay? I know obviously it varies from industry to industry, but have you seen that... Are people keeping up with these?
I hope so. We still see a lot of issues all over the place with API. So it's still very common 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 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 or some other almost independent third party that's coming in and really testing those things as they should be.
Right, because otherwise you're like, Hey, look, this is showing we still have room for improvement. It must be working. We've got a couple of things we can fix up and, we actually never peaked under the hood at our APIs. Yeah, that's a little eye opening. And I would be curious, if you can put on your prediction hat, I know we all love predicting the future. 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?
Yeah. I feel like we still have to cross over the worst parts to get there, but it's pretty close. Not to say something horrible is around the corner, even though it probably is, but do think those publicized incidents and bug bounty write ups with large bounties really bring the focus on those incidents to other big organizations to help close those items out. I've met with all the API security vendors and demoed their products, and I think 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 on to that, you know, you're gonna want a tool or a technique in place to test as far left as possible in the development cycle.
Then once 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 and logging any potential incidents and learning from those.
Yeah. Definite... I mean, for me, I I really like pairing together vulnerabilities. So if I could find an outdated version of the API, which is one of the top 10 findings, so improper inventory management is one of the new ones. And if an API is on version three and you go back and request version one and you're able to have a 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 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 favorite though is like, if you're, if you're dealing with a fintech API or banking API, and you're able to use broken function level authorization vulnerabilities, 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.
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 FBI folks listening. Just kidding. But, no, that's really fascinating. And I know that having its own OWASP top 10 just for APIs, I think speaks to the level of specialty involved here and that it is a different animal. And to that end, I'd be curious to hear more, tell me more about this book of yours. You have Hacking APIs, is that right?
Yep, that's right. So I wrote Hacking APIs. I started back in December 2019. I took 150 pages of notes in my research and I was like, hey, I'm halfway to a book. You know, I wanted to see publishers to be interested. I went to one of my favorite publishers, No Starch Press, and ended up teaming up with them, which was an awesome process. From there I wrote for a good sixteen 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.
And once, once all that was finished, then the book was released July last year in retail stores, which was awesome. Then in December of last year, I actually won book of the year with SANS 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, HTTP response codes, how to form an HTTP request, getting into the top vulnerabilities that affect APIs with OWASP top 10 included, but beyond that as well. And then from there, I wanted... The the books that helped me the most were the ones that had hands on labs. And so that was very important to me to include in there.
And there's two different... I feel like there's two different ways of doing labs in books. One is here's the problem. Good luck. You know, 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. The other way is what I did, which is more of a side by side lab. So here's the issue. Here's the thought process. 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. That's how I developed the labs in there. And after that came out, I wanted to create free educational course that anyone can have access to that gets them the basics of penetration testing API. So that's what I released over at APIsec University.
And for for me, you know, once you know how many... That 83 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 as an industry of testers and breakers, we're probably a few steps behind. So getting out that information and arming the testers as effectively as possible is really important and helping, you know, bug bounty hunters learn to test thoroughly for these vulnerabilities. I thought it was very important too. And so just getting that information out there for 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 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.
Yeah. For the API pentest course, really that was a more advanced course, like I said, having people dive straight into the hands on testing. So I think 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 of API security. And that one's approachable from the analyst to the C suite, high level security information that involves APIs. I do want another course that's gonna focus on the top vulnerabilities, really diving into each of those thoroughly, And then a basics course that if you're not familiar with web app testing at all, and maybe you're not familiar with penetration testing at all, that you could take that course, get an understanding of HTTP requests, the basics, the methods, response codes, and dive into API testing from there.
Stay tuned. Well, 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? Do board members need to know what an API is? Do CEOs... How big of an audience does this deserve at this point?
Yeah. The CISO, CTO should definitely be aware of their API attack surface. So what third party APIs do they depend on? Which ones are they consuming? What are they providing? And are those protected? So I think all of that is extremely important to grasp. CEO and above, like, how how much does the business rely on APIs, and what is the the risk there? So our resource is being dedicated to make sure that those are tested properly and that findings are remediated over a quick amount of time? Is there a bug bounty program where APIs are right in the spotlight for that? I think some of those things are important to know at a high level.
Well, has been a really illuminating discussion. Appreciate you sharing some of your expertise here with our listeners. And I do have one more question for you, which is something we ask all of our guests, and that's something we wouldn't know about you just by looking at your LinkedIn profile.
Gotcha. Yeah. So let's see. I have three daughters. They're all in elementary school. 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.
Oh, nice. Well, don't tap me for your Arkham Horror group game. I just... I can't handle it. It's too much. But I'll give it the old college try. But that's really that's really interesting. And maybe in DC, Scrabble I can do, the simpler ones, you know? Alright. Thanks Corey for joining us. Really, really insightful stuff.
If you liked what you heard today, I hope you'll give us a five star rating and review. It's a big help. And please share this episode if you know anyone who could appreciate a little infosec wisdom on their morning commute. We have a whole catalog of episodes well worth a listen, so you may wanna check out past interviews as well. Finally, if you know someone who might be a good fit to appear on the podcast or have any comments or feedback, drop us a line at we'[email protected]. That's s y n a c k dot com. Until next time.
API calls make up 83% of Internet traffic, which makes application programming interfaces an attractive target for attackers. Protect your APIs with adversarial security testing conducted by a trusted network of global security researchers. Find your results and how to fix critical security flaws all in one platform. Learn more at synack.com. That's synack.com.
