API Security Fundamentals – Course for Beginners

API Security Fundamentals – Course for Beginners

Show Video

Learn how to protect your APIs from modern security threats. In this course, you'll explore the OWASP API Security Top 10, analyze actual API breaches, and master the essential Three Pillars of API Security. Whether you're a developer or security professional, you'll gain practical knowledge to build and maintain secure APIs in today's threat landscape. Dan Barahona created this course. Hello freeCodeCamp community and welcome to APIsec University and this course on API security fundamentals.

My name is Dan Barahona and I'm one of the co founders of APIsec University. It's a site where we provide dozens of free API security courses, webinars, and conferences, and have over 100,000 students enrolled. In this course, you'll learn all about why attackers are targeting applications and exploiting flaws in their APIs. We'll cover the entire OWASP API Security Top 10, including real world examples of each one, and then provide practical guidance on what organizations can do to keep their applications secure. At the end of the course, you'll have an opportunity to take a final quiz and earn your certificate and badge. Thanks for watching and I hope you enjoy the course.

Hi and welcome to the API Security Fundamentals course. We created this course to raise awareness about API risks, share some best practices to help you keep your API secure, and provide a foundation for building a strong API security program. Now let's talk about what we're going to cover in the course . We're going to start with why API security? Why are we talking about API security? Why do attackers find APIs so appealing and we're going to explore how APIs are being attacked and why they're being attacked. We're then going to go through the OWASP API Security Top 10, and we're going to share a number of real world breach examples that highlight the OWASP Top 10. We'll then do an analysis of API attacks and really try to identify those primary drivers of breaches and where the root causes of vulnerabilities are coming from.

We'll then talk about what you can do to better protect yourself. This is a section we call the 3 Pillars of API Security, and we're going to talk about governance and testing and monitoring and different approaches for API security. And then we'll wrap up with some best practices, some really tactical information to help you keep your APIs secure and safe.

Let me tell you a little bit about APIsec University. We created this site back in 2022 to help educate the community on the risks of APIs and how to keep them secure. We definitely hit a nerve as we have over 100,000 students now enrolled in these free courses. I'd love to invite you to check out apisecuniversity.com, where you'll find additional

courses on topics like API Pen Testing, the OWASP API Security Top 10, API Security for PCI Compliance, API Documentation and Authentication, API Gateways and Product Management, and we're adding more all the time. We also provide free certificates for completing these courses. You can even earn your API Security Fundamentals certificate for the course you're taking right now. At the end of this course, you'll get a link where you can take our final quiz and receive your certificate and badge.

I hope you'll check out more of our courses. But before we get any further, let me tell you a little bit more about myself . My name is Dan Barahona. I'm one of the co founders of APIsec University. I've been in the cybersecurity industry for over 20 years.

I've led products teams, marketing teams, sales teams, and have held C level roles at companies like Qualys, ArcSight, Anomali and currently at APIsec.ai. I have engineering degrees from Rensselaer and Cornell University, an MBA from Michigan, and very much love to keep in touch, so if you want to reach out to me, there's my email address, there's my LinkedIn profile, please don't hesitate to reach out. Now let's get on with Why API Security next.

So next up, let's talk about why API security is such an important topic. But to get started, let's first talk about what APIs are. If you're not familiar, API is Application Programming Interface. Some people call APIs websites for machines. But if you think about it, APIs actually are present in almost everything we do online these days. Here are a few examples.

Let's say you're searching on Google for directions to a restaurant and then you want to book a Lyft ride or an Uber ride. How does that communication happen between Google and Lyft? That's all being done through APIs. Or if I want to send money to my barber from my Wells Fargo account, how does that happen? Well, Venmo is actually communicating with my bank through APIs as well. Or if I want to check airfares on Kayak across multiple different airlines, it's fetching that information through APIs. So APIs are really powering how the Internet works these days and have really enabled some really fantastic capabilities and integrations across organizations and within our applications, our mobile apps and the like. Now, let's paint the picture of what's going on out there in the real world.

And I call this the Perfect API Storm. So let's go through a few statistics. The first one is 83%.

And this is what percent of the internet's traffic is API powered. This is a study that was conducted by Akamai a number of years ago, and they found that 83 percent of the traffic on their networks was API powered. And this is really a testament to how great APIs, as a technology, have been, and how pervasive they are now.

They really are powering virtually every website, mobile app, and the like. But number one is where API attacks now rank. This is a quote from the Gartner Group. They predicted a number of years ago that API attacks would become the number one most frequent attack vector.

And you will see here that has certainly turned out to be true. And 4%, unfortunately, kind of represents the state of our API security. This is a survey done by RapidAPI, now owned by Nokia, and they surveyed their millions of users, what kind of testing they're doing on their APIs. And 96 percent of the responses were positive testing. Making sure it works properly; it's bug free, performs, integrates. And only 4 percent of respondents cited security testing on their APIs.

There's a reason why that number is so low, but we have to do better, and this is creating a perfect storm for breaches and attacks to take place. And let's look at what's being stolen out there. APIs are connecting to data, transaction engines, personal information, corporate intellectual property.

And there are a number of things that attackers are looking for. They're looking to steal credit card information. They're looking to steal personal information. They're looking to perform fraud. They're looking to scrape data.

APIs are really a very attractive target for attackers for all of these reasons. And this is really the tip of the iceberg, as you will see. But, why specifically APIs? What is it that makes APIs so appealing. And this very simple graphic really paints the picture.

If you look at where APIs sit, they are the glue, the connective tissue that make the internet work. Every time I log into my bank account, there's an API call. If I want to deposit a check, that's a different API call. If I want to transfer money, a different API call.

So APIs sit here right behind all that application functionality, and they enable all this to happen seamlessly. It connects the outside world to our internal applications, databases, transaction engines and such. And if there are any flaws in how those APIs are configured, the logic behind them, how they are set up, those flaws can turn into vulnerabilities and exploits. And one thing I want to address right up front is this notion that APIs are hidden and invisible and we don't need to worry about them. And we see far too many breaches occur for exactly that reason. So let me show you just how easy it is to find these APIs.

Here you can see I've simply gone to United Airlines. I'm looking up some fares and flight times and to find the APIs powering this interface it's really quite simple. And United hasn't done anything wrong here. I'm not picking on them.

I'm merely showing you how easy it is to find these APIs. All I have to do is within my browser, right-click, click on the inspect button, hit the network tab and there you go. You can see this API called Fetch Flights, and I can actually see the payload and understand the entire construction of that API request.

As I say, there's nothing wrong with this. My point is simply these APIs are not hidden. They're actually quite easy to find, and this is exactly what attackers are looking for. Now, let me show you how virtually every API attack takes place. What an attacker will do is they'll come to your site, they'll create an account, they'll install your mobile app, they'll utilize every feature and function of your application. And they're going to look for those API calls in the traffic.

They're going to monitor that traffic. They're going to search for those API calls in the traffic. And the next thing they're going to do is go around your UI and hit those API calls directly. Now, the reason why is if you think about your UI, it's a very controlled lockdown environment. I can only see the data that you show me.

I can only click on the buttons that you present to me. It's very controlled. But the API layer is completely uncontrolled. And what I mean by that is it's just a command line. And I can write any request I want and send it.

Nothing's going to stop me from doing that. And we're now relying on that back end to know if that request is legitimate, malicious or anything else. And what attackers are looking for at that API layer and what they often find are APIs that are over permissioned. They have access to more data, more functionality, more features than we expose necessarily in the UI. And they also expose logic flaws that might not be exploitable in the UI either.

And this is the fundamental reason why APIs are such a ripe target for attackers. Now, another reason why APIs are so appealing is if you look at how easy it is to perform these exploits. Let me just show you what the classic cyber attack looks like. We call this the kill chain. It's a very complex multi step process from performing your reconnaissance, infiltrating, weaponizing, moving laterally, Escalating your privilege and finally exfiltrating and causing that breach to happen.

That takes a high level of sophistication that most attackers don't have. On an API attack, though, this is what it looks like your attacker is going to poke around and probe and try to find a vulnerability in your API. And once they found it.

They can go straight to breach, and you will see many such examples here in the upcoming section. It's a far simpler attack pattern for attackers. So this is another reason why APIs are such an appealing target. And the regulators have very much taken notice of APIs. You can actually see here an example of a breach at T-Mobile where 37 million subscriber records got exposed through un unauthorized access to an API. They had the file a an 8K filing with the SEC to report this incident.

And here from Verizon, who owns TracFone, the Federal Communications Commission handed down a $16 million fine when they completed an investigation into subscriber data being leaked out through APIs and beyond the fine, they actually mandated a number of API security best practices. And as you can see here, they must now perform continuous, static and dynamic security testing of web apps, prioritizing APIs, with automated tools to test for vulnerabilities. This is one of the best practices that we're going to talk about in this course. The need to pressure-test our APIs proactively and continuously to find those vulnerabilities and remediate them. Now there are a number of other regulations out there that are really paying attention to APIs as well.

The Payment Card Industry, PCI, actually has a new DSS, Data Security Standard 4.0 that became mandatory in 2024. If you look at this PCI requirement, it has API security written all over it.

Things like looking for business logic abuse, abusive APIs, training for developers on API risks, and the like. You've got GDPR and really any privacy initiative out there, if your APIs are touching personally identifiable information, or healthcare, PHI, Protected Health Information for HIPAA, those APIs are very much in scope for your auditors. The SEC has a new regulation that's best known for its four day breach notification requirement.

But publicly traded organizations now have to report their security programs, including any risks to APIs. The United Nations has a whole cybersecurity requirement for automotive manufacturers and suppliers. And as we know, connected cars are all powered through APIs these days. When I unlock the doors or turn on the air conditioner from my phone, it's all API calls going to my vehicle. FedRAMP in the U. S.

government, if you want to sell and provide services, cloud services to the U. S. government, they have mandated monthly web application security vulnerability testing, including APIs.

And what does it all boil down to. All of these regulations, there's really three aspects to, to these regulations. One is security. Which is really to ensure the secure operations of our infrastructure, our applications and so forth.

And so we need to make sure where we have APIs that they are being set up, configured and operated securely. Then you have a privacy requirement. For example, with GDPR or CCPA in California or PIPEDA in Canada or many others, to protect the data of individuals. And if your APIs have access to any such information, then they're very much in scope for your threat modeling and your risk profile. We've got to make sure that we're addressing API security when we're looking at how to protect this regulated information.

But then we have a competing requirement. A data accessibility requirement. So, for example, in HIPAA, or in banking, there are requirements to protect the data, but there are also requirements to make that data portable and accessible.

And what that really means is it's mandated on organizations to utilize APIs to enable integration and data transfer. But we have to make sure that data transfer happens securely. Okay, and that wraps up the why we're talking about API security. In the next section, we're going to go through the OWASP Top 10, and we're going to go through a number of real world breach examples and explain exactly how those attacks took place. Okay, in this next section, we're going to go through the OWASP Top 10 and share some real world breach examples to reinforce the learnings and the requirements of the OWASP Top 10.

Now, if you're not familiar with OWASP, it is the Open Worldwide Application Security Project. It is a really fantastic organization, a non-profit that produces some of the best guidance out there for application security. And they actually are best known for their OWASP Top 10 for Web Applications. And back in 2019, determined that APIs have their own unique threats and risks and really deserve their own Top 10. And they came out with the OWASP API Security Top 10.

And in 2023 actually updated that to a new generation of the Top 10. There were some additions, some changes, some deletions that occurred between 2019 and 2023. But we're going to cover the 2023 edition here in this course. Okay, now here's what the top 10 actually looks like, and rather than go through these line by line, what we're going to do is break each one of these out into its own separate submodule, and we're going to describe what they are, and we're going to then provide an example to demonstrate that risk, vector, and then provide some best practices and guidance. Okay, but to get started, I want to share with you what the what's happening out there in the real world. And what we're seeing in the real world is really just an enormous volume of successful API attacks and breaches and exploits.

What you see here on this screen is just simply a small sampling of publicized API attacks that have taken place. And what we're going to do is take a look at a number of these and map them to the OWASP Top 10. And what you're going to see is a number of different threat vectors. We're going to see things like unauthorized trading. We're going to see account data harvesting.

We're going to see data exposure. We're going to see takeovers, tampering, reputation risk, ransom, and third party exposure. And what these attacks are really highlighting is that there's something about API attacks that are getting through the defenses.

All of these companies were employing the best practices, they all had web app firewalling, they were doing their source code scanning, and dynamic testing, and pen testing, and all these things. But something about API attacks is getting through those defenses. And that's what we're going to explore here in the rest of the course. And first we're going to start with OWASP #1. Okay, let's start with OWASP number one, this is known as broken object level authorization. You'll hear it called BOLA quite a lot.

It's number one for a good reason. It was number one in the 2019 list and also in the 2023 list. It's one of the most dangerous and difficult to detect threats.

And the classic example of BOLA is can user A access user B's data or can a user perform an action on an unauthorized object. These are authorization flaws and they're quite difficult to detect in runtime. It can cause very significant risk of data loss, as you will see. It can cause fraudulent transactions, as you will see here as well.

So let's share an example or two here. And the first example that I want to give you is from Coinbase. And here there was a researcher, a hacker, who wanted to poke around the Coinbase platform and see if they could find any flaws. like I mentioned earlier, the first thing they did was they came to the website, they created an account, they deposited some money, and they started utilizing all the features and functions of the Coinbase platform. Meanwhile, looking at all the API traffic.

And what you see here in this screenshot is what that traffic looks like when you do a trade. And you can see the elements of the trade here in the yellow boxes. The quantity, the price, you can see here, the product ID, that's what was being transacted here. In this case, it's this hacker was selling their Ethereum on the European market. And then you can see there on the Sell side and their are various accounts.

This was a valid request. They actually owned this asset and this would have processed just fine. One of the techniques that attackers like to use is to send intentionally erroneous requests in order to see what kind of error messages come out of your server. Many times, our error messages can not only be useful, but revealing.

And so he wanted to get an error message. So he took this request, which is a perfectly valid request. He owned this asset and he backspaced over the Ethereum, which he owned, and he typed Bitcoin on the US market, which he did not own.

And he hit submit and waited for the error message to come. Because clearly that transaction should not get processed. He didn't receive an error message. What he got back was a trade confirmation. And as you can see here down below, his $1,060 of Ethereum sold as $43,000 of Bitcoin. And much to his shock, I'm certain did not expect that to actually, to get processed, probably thought he might be going to prison and instead went on to x.com and, posted about this "potentially

market nuking" vulnerability and could anyone get him in touch with the CEO. Coinbase gets an awful lot of credit in my book, the CEO himself actually responded. They shut down the market. They were able to fix the issue within a matter of I think a day or so. And a week later they actually shared what was the root cause of this vulnerability.

And what they said though, is there was a "missing logic validation check" in their Brokerage API endpoint. And what that effectively means is that their application was checking the price, the quantity, but was not validating the asset ID. The Ethereum or the Bitcoin in this case. It just assumed whatever he was trying to sell was the asset that he actually owned.

And that's the missing logic check. So one of the takeaways from this example is that your UI is not part of security. In this case, there's no way this attack could have taken place in the UI. The UI prevents that type of abuse, that type of manipulation of the logic. But at the API layer as you can see, that was entirely possible.

So we often rely on the UI as a band aid, a cover for maybe some weak or missing logic that we might have. But as you can see, if the attacker can go around the UI, they can go around all those controls as well, so we really need to secure right there at the API layer. The next example I want to share with you is from Peloton.

The exercise equipment company. Here there was another hacker, a researcher that looked around the Peloton application and found all of these APIs. Quite a number of them were unsecured, meaning you could query, you could utilize these APIs without providing any credentials. And one of these API endpoints had access to the entire four million user Peloton database. And so they actually notified Peloton of this exposure.

And Peloton then took action and fixed the issue. They took that unsecured API endpoint and locked it down. You can no longer query it anonymously. You have to have valid credentials in order to access this API.

But the problem was, anybody could go create an account on Peloton, and utilize those credentials and access this API, and still access 4 million users records. And this is the difference between authentication and authorization. They addressed the authentication issue, which is is Dan actually Dan, but they did not address the authorization issue, which is, can Dan access other Peloton users records? Now, both of these examples, Coinbase and Peloton are great examples of OWASP # 1 Broken Object Level Authorization, and really demonstrate the risk that comes from not having properly configured authorization logic in your applications. So what are some of the best practices? Really, we want to move security as far left as possible. So when you're in the design phase.

For a new application or new API let's make sure that security is in the room at the whiteboard, bringing their concerns and requirements to the product needs. Let's review those requirements. Let's understand what data the APIs are going to touch, what data they're going to have access to and make sure there's logic, there are controls in place to prevent this type of cross account contamination.

Then you want to enforce those controls. And test those controls to make sure that they're actually working as designed. And these are the types of things that really need to be implemented during the software development phase and can't really be addressed in a web app firewall or some sort of runtime role. So it's really critical that we address these types of authorization flaws up front. Okay, next up is OWASP # 2 Broken Authentication.

This is really defined as weak or poor authentication on our APIs. Could be no CAPTCHA, no two factor authentication, brute forcing, credential stuffing and these types of things. What we often find is no authentication. Quite a few API breaches are happening because APIs are left completely unsecured with no authentication whatsoever.

And of course, the risks are obvious. If we've got poor or missing authentication on our APIs, that's exposing whatever that API has access to. As we saw already at Peloton, they had an unsecured API that had access to all of that user database information. This could lead to data harvesting, could lead to abuse of your APIs through unauthenticated requests, ransom, PII, personally identifiable information harvesting and the like. Now, the example I want to share with you here to demonstrate this is from Duolingo language learning app.

I imagine many of you taking this course are Duolingo users. I myself am a Duolingo user. And as you can see here, over 2 million records were exposed through an API. And here there was another hacker that poked around the Duolingo platform, found a number of APIs powering this application, and quite a number of them left unsecured. Meaning you could query them without any credentials whatsoever. But the way this API worked was if you supplied an email to the API, it would respond and let you know is this an active valid user on the Duolingo platform? And a bunch of profile data about that user.

So as I mentioned I'm a Duolingo user myself, so I tried it on myself and this is exactly what happened. I'm not that sophisticated technically. I could even do this from a browser. All I had to do was to append my email address and immediately I got all of this information about my Duolingo account. The streak, what languages I'm learning and so forth.

But the key is, I could do that with any email address, my child's email, my next door neighbor's, your email, anybody's, and I could have done this as well. And this is a great example of Broken Authentication, an API that is left without any real controls preventing abuse or users from accessing it. Now, why do organizations sometimes leave these APIs unsecured? Seems obvious to lock them down. We know there's a lot of pressure, a lot of demands on developers to fix bugs, to hit release dates to release new features and functionality. And there is a misperception that API's are hidden and don't really need to be worried about.

But of course, as you can see here, attackers are specifically looking for APIs So let's make sure that we're considering authentication in the design phase of our applications. Let's make sure we're considering what types of controls and how we need to authenticate users. And that needs to really be tailored to the sensitivity of the application. If your app is simply checking the weather, you might not need any authentication whatsoever. If I'm able to set my password or transfer funds from a bank account to another account, you really want to elevate that authentication as well.

And make sure you implement continuous testing to ensure that your APIs and your applications are functioning as expected. That authentication is in place and being enforced. And please don't assume your APIs are secure just because they're hidden from regular users. They're not that hidden as we've shown you. So let's make sure we lock the door. Okay, next up is OWASP API 3 which is Broken Object Property Level Authorization.

This is a merger of two categories from the 2019 edition, Mass Assignment and Excess Data Exposure. Mass Assignment really has to do with the ability to manipulate and modify data through the APIs in unauthorized or improper fashion. Excess data exposure reflects the risks of APIs revealing too much information, whether it's volume of information or the type of information. My personal information, my bank account information, my home address and so forth.

example of Mass Assignment might be a user setting their account type from free to premium. That's an example of a data manipulation. Or APIs that return too much information, unnecessarily verbose information, high volumes of information. Naturally there's a number of risks here Broken Object Property Level authorization, which you may also hear called BOPLA. Now the example I want to share with you is from Venmo, the payment platform. It's a social platform, so on their homepage they had a feature that would show you the last 10 or 20 transactions in real time, but anonymized data, naturally.

So it might have my first name, but not my last name or account details. But as you can see here this attacker found the API powering that feature of the homepage. It was a public API, no authorization required. So they could query it to their heart's content. But here's the key.

When they queried that API directly, as opposed to viewing it through the UI, the API did not return anonymized data. It returned to the whole record. First name and last name and so forth. And so they wrote a script and harvested over 200 million transactions out of the platform in full, complete detail.

What's the takeaway here? We need to make sure we're tailoring our APIs to the use case. And there's a best practices known as data minimization. Which is simply don't return a single field more than the business case requires. In this case with Venmo, they probably should have created a special API that only returned those fields that were going to be presented in the UI.

Instead, they relied on the UI as a filter. The API returned far more data, but they simply filtered it in the UI. In terms of best practices and prevention we got to make sure that the API only returns the data that is necessary for that business use case.

Return the minimum amount of information and not a field more. These requirements should all get defined early on in that design phase of your APIs. This is why we want security in the room during the design phase. So we're ensuring that the APIs are not revealing more information than necessary. And let's make sure we test our APIs.

This is a great way to identify overly verbose APIs. There are very good automated tools that will look at your API responses and identify credit cards, email addresses any other PII or sensitive information. And from the Mass Assignment side we've got to make sure that we set proper controls over not only what data can users see, but what data users can manipulate.

So we've got to make sure we have the proper controls in our logic to prevent that kind of abuse. Alright next on the OWASP list is # 4 Unrestricted Resource Consumption. They just changed the name. It used to be called Lack of Resources and Rate Limiting here, but really this is meant to address any kind of volumetric or brute forcing of our APIs here.

Examples are, pretty obvious. Things like mass data harvesting, not having a proper rate controls enforced on our applications. But it could be also things like lack of proper execution timeouts or not controlling the maximum memory or number of lines returned or the upload file size. These are all examples of how brute forcing can take place on your API. And it can result in things like excessive operations, excessive data being returned, denial of service, degradation of performance of your application. So this is really one of the most important and probably most common examples of an API threat that we see out there.

Now, the example that I want to share with you here comes from Trello. If I want to invite you to my Trello project, there's a feature where I can simply provide your email address and a backend process will send you an invitation to my Trello project. That backend process is powered by an API.

That API is publicly accessible and was unsecured. And when this attacker found this, what they discovered was they could send an email address into that API endpoint the Trello API would reply with, is this a known Trello user and a bunch of profile information about that user. When the attacker found this they knew that they could harvest a lot of information. So they went on to the dark web, and they collected 500 million email addresses from prior breaches and they sent 500 million requests at this API. This is a perfect example of Unrestricted Resource Consumption. Now, you may be thinking, shouldn't the rate limiting shouldn't the WAF, the gateway have prevented this type of mass abuse of the API? And those are all technologies that you should implement to prevent this type of abuse.

But attackers are quite clever. And we know in this case with Trello, they had a web app firewall in place. They probably had other forms of rate limiting and bot detection.

So how were they able to send 500 million requests? Attackers are clever and determined. And they probably ratcheted up their requests until they hit that rate limit ceiling. And then, dialed it back by some small amount and just flew under the radar. They distributed their attacks across thousands of IP addresses. They might have used residential proxies and all of these things to evade detection. And certainly this attack would have taken months if not longer to execute.

So a determined attacker is going to find their way around things like rate limit defenses and other things. So what could Trello do about it? As you can see here, Atlassian, the owner of Trello, they made a change to their API so that unauthenticated users could no longer request the information of other users. They simply took that unsecured endpoint and they made it secure. And that was a very effective response here.

And the reason why is it's far easier to detect abuse in the form of 500 million requests coming from Dan than 500 million anonymous requests. So simply by being able to associate that traffic to the source user, they could really mitigate this type of risk going forward. So what do we want to do to address this? Of course we want to implement traffic controls. Whether it's a web app firewall or an API gateway. But we have to understand that those traffic controls are not silver bullets.

A determined attacker might find their way around it. We gotta make sure we're testing the effectiveness of those controls. And we gotta make sure that even if those controls don't prevent this type of bot attack, or high volume brute force attack that our APIs are not revealing information that we don't want out there in anonymous users hands.

So using authentication to control who can access data and what they can see is really critical here. All right, OWASP # 5 is Broken Function Level Authorization. And it's what we saw with OWASP # 1 Broken Object Authorization, except instead of looking at what type of data a user can access, here we're talking about what type of functions they can perform. So it's an abuse of functions. Are there transactions? Are there capabilities like being able to reset someone's password. That should only be possible on my account, not on your account.

So you have to control not only the data users can access, but the functionality that they can access as well. We'll often see things like replacing passive methods on APIs like GET, which are really lookup type methods, with active methods like PUT and POST and DELETE. And the risk is quite obvious here. The ability to perform functions like escalate your privilege, convert my free account into a premium account, modify other types of account information. I could also do things like delete an invoice or set my car loan balance to zero or to a negative number.

It's really crucial that we are controlling what functions users can access and with what permissions. The example I want to share with you here comes from Bumble. This is a very popular dating application. And on Bumble there are two user types.

You can have a free account or a paid account. And there's an API where you can look up what account you have what account type you have. That is called a GET request. Just tell me what type of account and it will respond with free or paid or whatever account type you have. But they also exposed a function to modify that.

Maybe it was a POST method on that same endpoint. So not only could I look it up with a GET request, I can modify it with a POST request. And say, change my account from free to paid. And that's exactly what happened here at Bumble. And so anyone with the cleverness to know how to use that API, they could simply elevate their account without ever making payment. , Now that elevation of a user account should only have been possible by requiring the user to provide their credit card and completing a transaction and then a back-end process would elevate the user.

This is a function that should never have been exposed to the end user, So this is the authorization flaw. The user should not have access to that particular function. So in terms of prevention here. We need to identify what those functions are. What those methods are, what those endpoints are that are performing sensitive actions and make sure that we have the right logic and controls in place to limit access, to prevent users from accessing those functions and performing some sort of malicious or inappropriate or abusive type of request. So another great opportunity for testing.

We want to test the permissions of every user type against all of our endpoints and identify any gaps or overlaps or areas where a user could access a function we don't want them to have access to. This is where RBAC, Role Based Access Controls, comes in. We gotta make sure we're testing all of those different roles across all of our different endpoints to ensure that there isn't any drift or changes , in our permissions that we don't know about that can create this type of exposure as well. OWASP API 6 is actually one of I think the most important additions to the 2023 Top 10.

It's Unrestricted Access to Sensitive Business Flows. And why I really like this as it introduces the concept of business flow, business logic. And as API developers, as application operators, we tend to think about does the application work as designed? Can I, purchase that sneaker or book the vacation or transfer money or all of these things. We want to make sure it works as designed. But what we're talking about here is can that business flow be manipulated? Can it work as not designed? Can it be misused or abused? Here we're typically going to see an abuse of a legitimate flow in ways that wasn't intended. Often we're talking about excessive use or some sort of automated abuse of that business flow.

And this is almost always the result of some kind of logic flaw. There's a condition that we didn't consider in developing our application that created this exposure. And the types of exposure we're talking about here is loss of business through some sort of abuse of a business flow could be, loss of concert ticket sales or high volume referral purchases or brute forcing incremental IDs to gain access to features and functions and account information and so forth.

So there's really an endless possibility here. We're talking about logic flaws that can be exploited. And the example that I want to share with you here comes from Instagram. So on Instagram, if you wanted to reset your password, there's a perfectly good business flow for doing that. But that business flow logic could be exploited to take over another user's account. So let's say, for example, you wanted to take over Taylor Swift's Instagram account.

You would go to Instagram, pretend to be Taylor Swift and say I forgot my password and would send a six digit code to the real Taylor Swift, which you would not get. But it turns out there's an API where you can submit your guess Six digit code. That's a million combinations. So all you got to do is start at 1 and keep incrementing and eventually you'll hit the right reset code. But there were some protections in place that Instagram had implemented. Number one, there was a 10 minute timeout.

So after 10 minutes, you couldn't submit any more guesses, but that's frankly plenty of time to send a million API calls. And there was also a 200 guess limit. And at this point, I think this hacker thought they were done, it wasn't going to work. But they tried one last thing, they rotated their IP address and much to their surprise, they got 200 new guesses. So they could simply keep changing their IP address, making 200 more guesses each time, automate that, distribute it, and get through all million combinations well within the 10 minute timeout. So what is the moral of the story here? We need to think not only of how our APIs are meant to be used, our applications are meant to be used, but also how they can be abused.

In this case, with Instagram, there was a perfectly good logic, business logic for resetting your passcode. If I forgot my password, I could use this feature and get access to my account again. But the way it was implemented created its own exposure, its own exploit.

And there were a number of things that could have done differently. Number one, IP address really shouldn't have entered into the equation. The number of IP addresses you use shouldn't affect how many times you can guess at that reset code. Number two, 200 guesses, probably too many.

Four or five is probably enough. And then expire the code. It's no longer valid.

If you've tried more than a few times, that code no longer becomes active. You've got to request a new code. And number three would be to stay away from incremental IDs.

By making it an incremental or numerical reset ID, you're simply saying to the attackers the reset code is somewhere between one and a million. Good luck. And we know incremental IDs are very convenient for developers, but as you can see, they're also very convenient for attackers. For brute forcing, for guessing at IDs and so forth. So let's stay away from these incremental IDs as well.

And so from a prevention standpoint, we've really got to make sure we train ourselves as API developers, as product managers and security teams to not just think about the happy path. How the application is meant to utilize that function, but also the potential for abuse. How an attacker might try to manipulate that logic to perform some sort of malicious activity. All right, the next one on our OWASP API top 10 tour is #7, SSRF, Server side Request Forgery. This is a new entry for the API Top 10. It appeared in 2023, and the goal of SSRF is to trick your server into going somewhere that it really doesn't belong.

It involves exploiting URL inputs to make requests to a malicious third party or to access internal resources that external users shouldn't be able to access, and it often involves exploiting flaws in the permissions of your server, leveraging excessive permissions on that server to target another system. The harm from SSRF can be extremely significant. If you're vulnerable to this type of attack, it can create a channel for malicious requests.

It can expose internal data and other resources to external users. Examples involve users inputting unexpected values. So imagine you have an application where you request the user to provide their LinkedIn profile URL. And imagine instead of giving you something that starts with linkedin.com, they give you something that points to a malware site or to /localhost/etc/passwd.

If you're subject to an SSRF vulnerability, you might find that server actually going to those locations and returning that data to the end users. Now it's difficult to find published examples of SSRF exploits, but here's one that will really highlight to you the exploit channel and the potential harm. Okay, this example comes from Capital One, where back in 2019, an SSRF exploit allowed an external attacker to steal credit card applications, social security numbers, and more.

And what happened was the attacker exploited a misconfiguration in the WAF, the web app firewall, to access highly sensitive internal resources on AWS S3 buckets. In this case, the WAF had excessive permissions and would relay any external requests leveraging those permissions. In this case, the attacker used those WAF permissions to send a request to list all of the S3 buckets it had access to and then download and decrypt all of that information. In this case, over 30 gigabytes of data was harvested through this malicious request, including over 100 million credit card applications, 100,000 social security numbers and more, and also resulted in a fine of $190 million. So as you can see, SSRF can really create significant harm, especially creating that channel for external users to access malicious sources or internal repositories. So what do we do to prevent this type of breach? First, I highly recommend you utilize the Least Privilege Model.

In this case, the WAF had excessive permissions and it leveraged those permissions to relay requests from an external user. So let's limit what kind of permissions those servers have. Let's not trust any inputs that are coming from users. Put them through an input validation check first. So if you're expecting a LinkedIn URL to be provided and you get something that doesn't start with linkedin.com, then throw it away. That's not adhering to the expectations of your application.

And then simulate these types of attacks, these types of SSRF requests on your APIs. And see if you actually have those types of vulnerabilities present in your application. All right, next on the list is OWASP API #8, Security Misconfiguration.

This is really a kitchen sink of standard best practices for running and operating your API servers. You really want to make sure you're handling all the "blocking and tackling" to make sure your servers are properly hardened and patched. You've implemented the right policies and controls. Attackers are going to use bots and other automated tools to scan your sites, your servers, your applications, your APIs and look for any gaps in these controls. So make sure you're validating these continuously.

And here are some examples of the types of best practices you should be implementing. Things like server hardening, unpatched systems not turning off unnecessary services, not using encryption not setting header parameters like CORS and rate limiting and HSTS. Having insecure cookies, and so on. We actually have a whole course on APIsec University that's dedicated to this topic.

It's called Securing API servers. If you want to learn more about this whole topic, definitely recommend you go check it out. Now, the example I want to share here is from Experian and it involves not properly controlling access to a highly sensitive API.

In this case Experian the consumer credit monitoring firm they created a private API for the exclusive use of their trusted partners so they could look up credit scores of loan applicants and so forth. One of those partners thought it would be cool to create an application where loan applicants could check their own scores. And so they built this application leveraging the Experian API. A hacker found that application and wondered how is this working? How is this site able to look up the credit scores on any loan applicant? And so they tried the application directly and they found the APIs, the Experian APIs that were powering this feature.

And all it required was to provide a user's name, their address, and their birthday. So they probably tried it on themselves and it worked. With no password or credentials or anything like that. They probably then tried it on a family member. They knew their name, their address, their birthday.

And it also worked. And maybe they tried it on their neighbor. Where they knew the name, they knew the address.

But maybe didn't know the birthday. And so they just put any value in the birthday field. And it still worked. Turns out as long as you put any digits in the birthday field, you could put all zeros, and it would still work. So by improperly controlling access to this API, the credit records of virtually every adult American was made accessible through this application.

So what's the prevention advice here? It's pretty clear. You want to do all the standard blocking and tackling as I mentioned. So make sure you're hardening and patching all of your API infrastructure, enforcing proper headers and policies like CORS, cross origin resource sharing, HSTS, rate limiting, making sure your error messages are helpful, but not revealing. Don't include any information that could help an attacker understand your infrastructure or what types of values are being expected.

Prevent things like path traversal and server information leakage. And set up a program to review your security configurations. Make sure there isn't any drift or anything like that. Set up automated testing to look for any changes that were unexpected. And do check out the Securing API Servers course on APIsec University. It's got a lot more useful information.

#9 is a new entry on the 2023 API Top 10, Improper Inventory management. And although it's way down at #9, it's actually one of the most common areas that I get a lot of questions about. Improper Inventory Management has two main aspects to it. The first is awareness and visibility. Do you know all the APIs running in your environment? And the second is control.

Once you know what APIs are running, should they be running? Are they up to date? Have they been retired? Are where are they running? Who created them? Do they have vulnerabilities? Are they properly documented? And so on. And you'll often hear about things like zombie or shadow APIs. APIs that are out there running, but no one seems to know about them.

Or you might have out of date, older versions of APIs that are still accessible. And version control. If you have an API running on yourdomain.com/api/v3,

I guarantee you when an attacker sees that they're going to try V2 and V1 and anything else they can dream up. And often those older versions hang around, they still exist. Maybe you've got a customer or a partner that refuses to upgrade to the latest version. And those older versions don't have the same level of security scrutiny. We're not testing them, we're not evaluating them, we're not updating them.

So make sure you're properly retiring those old versions. The example I want to share here is from Optus, a large Australian telco provider. Here, there was an internal engineer who decided to create an API that had access to a lot of subscriber information. And that API was made publicly accessible.

And there were a number of issues with how they did this. Number one, they made that API publicly accessible with no authentication, no credentials required. Secondly, that API had access to Significant amounts of personally identifiable information in this case, 9.8 million subscriber records,

including driver's license numbers, phone numbers, dates of birth, home addresses and the like. And third, this API leveraged incremental IDs. So in this case, the databased used incremental IDs for all of the subscriber records, making it very easy for this attacker to simply increment and harvest all of this information in massive volumes.

Now, what they did was they exfiltrated all of this information, 9.8 million records. And what you can see here on the screen is them attempting to extort $1 million from Optus to prevent the unauthorized exposure or sale of these 10 million records. This caused a major outcry in Australia, even the Prime Minister of the country got involved, and it really elevated awareness of API risks across the country. And this breach was all made possible because there was an unknown API that got published without any awareness from any of the security teams. So the first thing that I recommend is that organizations sit down, create a cross functional team involving security, development, operations, compliance, risk, and define your API policies and processes.

This is really where governance comes in. It shouldn't be possible for a random engineer to create and publish an API and get it out there onto the internet. We should have very standardized processes for deploying APIs. Next, you have to know what your API ecosystem looks like. You'll often hear the term API discovery a lot, and unfortunately I'm here to say there's no easy button here.

There's not one single thing you can do and you will magically have a complete and comprehensive API inventory. But here are some of the common approaches. There's traffic based discovery, which basically involves watching the traffic coming in and out of your applications, your environment, and seeing what API calls are flying across the wire. Now, I recommend you talk to your WAF provider, your web application firewall provider, because many of them now have API discovery functionality built into their products. They're already watching the traffic.

They can now identify those API calls. Next is code based discovery. Here, we're talking about scanning your code repos to look for any API endpoints that exist there. There's app crawling discovery, which is basically crawling through your application, exercising every feature and function of your app and looking for the API calls that are sitting behind them.

There's dictionary discovery, which is really a brute force approach. There are many published lists of hundreds of thousands of lines long of common API paths. So you can simply run these against your applications and see which ones are present. But one of the methods of discovery that's probably most overlooked is what I call the go talk to engineering approach.

I've met many security teams who will tell me things like we don't know what APIs we've got and that's understandable. But I've never heard that from an engineering leader. They have a pretty good handle on what APIs are being built and run in their teams. It might not be 100%, but by having this discussion with the engineering team, not only will you build a collaboration, a dialogue with that team, you're probably going to get a pretty good sense of what APIs are out there, especially for the most important business applications that are running.

I strongly recommend deploying and managing all your APIs in a common API gateway. This is a great way to maintain visibility and awareness, but also to centralize policies, and to be able to deploy common policies across your APIs. Make sure you properly retire all your APIs. And make sure your clients, your partners, all upgrade to the latest versions. And finally, do a periodic audit to make sure you know who's got access to your APIs.

There aren't any organizations or users out there that really shouldn't have access any longer. All right, we've reached the last entry of the OWASP API Security Top 10, Unsafe consumption of APIs. This one is also a new entry in the 2023 edition, and I like to think of this as the reverse of OWASP #9, Inventory Management, which is focused very much on your internal API environment. 10 is really all about your external API environment, those third party APIs that you might be using now.

Most organizations are now integrating with dozens or hundreds of third party providers, via their APIs. And we cannot just assume that because an API comes from Salesforce or DocuSign or Stripe or anyone else that they're safe and free of vulnerabilities and cannot be hacked. And sometimes it's not even an issue of the API itself, but more about how we integrate and implement it in our own code. An improperly integrated third party API can lead to data theft, breach, account takeover, and other exploits.

And like SSRF, it's hard to find some published examples of third party API breaches. But here's an example that absolutely highlights how an API flaw in another application can cause harm to you if you're not careful. This example involves Companies House, which is a department of the UK government, where organizations can register their businesses. And in this case, an individual decided to register a business with a name that incorporates a cross site scripting attack. You can actually see the name here. It starts with a quote and a bracket and then script and source.

And this actually leads to a cross site scripting script. And so this individual registered that long string as their company name. And if you were to pull up this record in the Companies House database, it would actually execute that script.

Fortunately this individual had nothing malicious in mind and it would simply pull up a humorous alert, but it could have been far worse. And it really demonstrated that simply by registering this unique name could actually invoke a cross site scripting attack. And beyond that, any other sites that were using the Companies House data might also be exploited if they didn't do their own input validation. And ultimately, this individual was forced to rename their business, which you can still search for and find on the Companies House website. It's now called That Company Whose Name Used To Contain HTML Script Tags LTD.

So what should you do about third party API risk? First of all, know what third party APIs you're actually using. This can be a little tricky as you might not find those APIs in a code repository or an API gateway or some central repository like that. Second, do not assume that third parties are inherently safe and trustworthy. Just because you're utilizing an API from someone else doesn't mean that they are perfect. That means treat them like your own APIs. Do your own input validation.

Test your own authorization rules, make sure user A can't see user B's data or any other cross account contamination or any other OWASP vulnerability for that matter. And why not ask your third parties to demonstrate their own testing? Show you their API pen testing reports and what are their programs for making sure their APIs are safe and secure. And you can also do your own API testing. Just make sure you check your license agreement and don't violate anything, but we strongly recommend you test those APIs just like you would your own APIs. And that wraps up the OWASP section of this course. We've gone through a lot here.

We've gone through all of th

2025-02-02 05:51

Show Video

Other news

NEW AI Tools For 2025 (Must Know!) 2025-02-14 20:06
How 10,000+ High Tech Machines Are Changing U.S Farming Forever – Farming Documentary 2025-02-15 05:35
Tech Lifts Hong Kong Stocks to Three-Month High | Bloomberg: The China Show 2/7/2025 2025-02-09 03:25