OWASP API Security Top 10 – Secure Your APIs

The OWASP API Security Top 10 is a standard reference guide highlighting the most critical web API vulnerabilities to help developers and organizations understand and mitigate potential security threats.

We just published a course on the freeCodeCamp.org YouTube channel that will teach you about each security risk and techniques to fortify your APIs against potential threats.

Corey Ball developed this course. He has emerged as one of the leading experts in API security and is the author of Hacking APIs.

Here are the sections in this course:

Course Objectives

• What is the OWASP API Security Top 10
• What is OWASP
• How is the Top 10 Compiled?
• Mapped to External Sources
• Updates to the OWASP API Security Top 10

The Top 10

• API1:2023 - Broken Object Level Authorization
• API2:2023 - Broken Authentication
• API3:2023 - Broken Object Property Level Authorization
• API4:2023 - Unrestricted Resource Consumption
• API5:2023 - Broken Function Level Authorization
• API6:2023 - Unrestricted Access to Sensitive Business Flows
• API7:2023 - Server Side Request Forgery
• API8:2023 - Security Misconfiguration
• API9:2023 - Improper Inventory Management
• API10:2023 - Unsafe Consumption of APIs

Beyond the Top 10

• Injections
• Insufficient Logging & Monitoring
• Business Logic Flaws

Watch the full course on the freeCodeCamp.org YouTube channel (1.5-hour watch).

Transcript

(autogenerated)

The OWASP API Security Top 10 is a standard reference guide highlighting   the most critical web API vulnerabilities to help developers and organizations understand and mitigate potential security threats.

In this course, you will learn about each security risk and learn techniques to fortify your APIs against potential threats.

Corey Ball developed this course.

He is a cybersecurity consultant and a leading expert in API security.

So he's the perfect person to teach you how to secure your APIs.

Hello, freeCodeCamp community and welcome to APIsec University and this course on OWASP API Security Top 10 and Beyond.

My name's Dan Barahona.

I'm the co-founder of APIsec University, and for the next 90 minutes, you'll learn all about the OWASP API Security Top 10, updated in 2023, and we'll even add a few extra bonus topics that are really important to know about.

Your instructor for the course is my good friend, Corey Ball, author of the Hacking APIs book and well-recognized expert in the field of API security.

I invite you to check out all our free courses over on APIsec University, including a hands-on course on API Pen Testing, an introductory course on API Security Fundamentals, this course here on the OWASP API Top 10, as well as a PCI Compliance course, an API Documentation course, and many more to come.

All the courses on our site include quizzes to assess your knowledge,  and if you complete everything and pass the final quiz, we'll issue you a certificate and badge to recognize your accomplishment, which you can also display on your LinkedIn profile.

Thanks again for watching and I hope you enjoy the course.

Welcome to OWASP API Security Top 10 and Beyond.

In this course, we'll dive into the latest updates to the OWASP API Security Top 10, and discuss other significant security considerations beyond the Top 10.

The first edition of the API Security Top 10 was released in 2019, and now OWASP has officially released the 2023 version.

As APIs are a critical component of the modern digital world, this list is of utmost importance.

This course highlights the most common API security vulnerabilities and is meant to help educate the community of builders, breakers, and defenders.

The course will help you identify and analyze the most common weaknesses that plague modern web application programming interfaces, or APIs.

By the end of this course, you should have an understanding of the variety of vulnerabilities associated with APIs, the attack vectors involved, and the technical impact and exploited vulnerability could have.

So who is this course for? This course is great for anyone involved in the API economy.

It is meant to help improve the skills and knowledge of bug bounty hunters, developers, penetration testers, organizational leadership, and anyone else interested in learning about API security.

Before taking this course, you should be familiar with API security fundamentals.

If you would like to learn more about this, check out our API Security Fundamentals course.

So how does this course work? Read, watch, and or listen to the content provided in the course modules.

It is highly recommended that you take notes, explore the recommended resources, follow along with the course materials, and complete the quizzes at the end of every module.

The content presented in the video should closely align with the written content.

The videos offer visual and audible alternatives to consuming the content of this course.

Quizzes During the course, quizzes will be used to validate your knowledge.

Quizzes are knowledge-based, multiple choice tests based on the content discussed within the given module.

The OWASP API Security Top 10 and Beyond course is meant to be a challenging course that sets a high bar.

To pass any quiz or assessment, you must answer a hundred percent of the questions correctly.

Completing all quizzes will result in obtaining a  certificate of completion.

This course is entirely free, and you can earn the certificate of completion by passing all course modules and passing all the quizzes.

Those who would like to certify their knowledge can take the course exam.

The exam is a knowledge based assessment of your ability to analyze APIs and find vulnerabilities.

Students who pass the exam will earn the Certified API Security Analyst certification or CASA.

Formatting Please note that all content in italics under sections designated OWASP is sourced directly from the OWASP API Security Top 10 2023.

This content is attributed to the OWASP API Security Project Team and OWASP API Security Project contributors.

All other sources will be directly referred to.

No changes were made to the content.

Hey everyone.

Quick introduction.

My name is Corey Ball.

I'm the author of Hacking APIs, technical editor of Black Hat GraphQL, and contributor to the OWASP API Security Top 10 2023.

I'm also the Chief Hacking Officer for APIsec University and a Senior Manager of Penetration Testing over at Moss Adams.

I have over 13 years of experience working in IT and cybersecurity across several industries.

In addition to a Bachelor's degree in English and philosophy from Sac State, I also hold several certs including the OSCP, CCISO, CISSP, and several others.

I hope you enjoy this course.

The objective of this course is to help students become API security professionals, and be able to identify and reduce API related security risks.

OWASP API Security Top 10 and Beyond is meant to help improve the skills of bug bounty hunters, developers, penetration testers, organizational leadership, and anyone else interested in learning about API security.

Course objectives include the introduction to OWASP, the API Security Project, and the changes from the 2019 to the 2023 version.

Should help prepare students to pass the Certified API Security Analyst or CASA exam.

Develop a strong foundation in the following API security risks: Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, Server Side Request Forgery, Security Misconfiguration, Improper Inventory Management, Unsafe Consumption of APIs.

In addition to that, it's to help secure the APIs of the internet and prevent API related data breaches.

Finally this course is meant to help prepare students with additional resources for continued learning and growth in API security.

The Open Web Application security project, or OWASP, is a nonprofit foundation that was created to help improve application security.

The OWASP Foundation launched on December 1st, 2001, and is most well known for its Top 10 list open source tools and other security projects.

The OWASP API Security Top 10 is a list of the most critical security risks for application programming interfaces.

The founders of the project include Erez Yalon and Inon Shkedy.

The OWASP API Security Top 10 was originally released in December, 2019 and was driven by several key factors.

The first was the rapid rise of APIs.

APIs power the flow of the world's most valuable resource, which is data.

A business no longer needs to specialize in all aspects of creating software.

Instead, they can use the features of software shared by other companies and organizations.

Historically, the issue with doing this was the disconnected nature of different programming languages, web application programming interfaces allowed for a common method to consume or provide data across the internet.

Since the widespread adoption of web APIs, organizations have been enabled to leverage the functionality.

Of other applications.

Instead of having to develop custom software for maps, gps, payment processing, authentication, communication, and much more, developers can leverage APIs to use the functionality of other applications that specialize in that given area.

APIs are a major business enabler, which explains the global rapid adoption.

Second, a major gap in security.

So the next factor that compounded the effects of the other two is the fact that the tools and techniques of the past were not effective at detecting API related vulnerabilities.

The tools and techniques that were used for enterprise vulnerability management programs, web applications, scanners, and traditional network security monitoring tools were not designed to handle the unique challenges posed by APIs.

As a result, many organizations were not adequately prepared to defend against API attacks leaving them vulnerable to data breaches.

Third, a new leading attack vector.

Often when it comes to the rapid adoption of new technologies, security is an afterthought.

APIs are no different.

The rapid adoption of APIs led to a new attack vector that exposes data application functionality.

Public internet facing APIs often bypassed all of the security measures that had grown with businesses over the past decades.

An attacker no longer needs to go through the classic MITRE cyber kill chain by bypassing the firewall, gaining entry to the network, pivoting around to system that contains data, and then finding a way to exfiltrate that data.

Instead, an attacker can use an insecure API and have direct access to that sensitive data.

In response to the massive adoption of APIs, the security gaps introduced by API providers, and the new wave of API related security incidents, the OWASP API Security Project published its Top 10 list.

The API-focused Top 10 list provides a comprehensive set of guidelines, best practices, and tools to help organizations secure their APIs and protect against API related threats.

The OWASP API Security Project has become a widely recognized and respected resource for security professionals and has helped raise awareness of the importance of API security.

How is the top 10 compiled? As described by Paulo Silva, OWASP API Security Project leader, the 2023 OWASP API Security Top 10 list is put together by the project team based on internal research, based on publicly available data, bounty platforms and news.

Since the project did not receive any data during the call for data during the two month window in late 2022, the top 10 list was compiled based on the project team's research.

This was not something new or different for the project as this is, as Silva stated, what was done in 2019.

Without dataset received from the community, the OWASP project team had to compile data based on public disclosures from bug bounty pro platforms and API security incidents that made it into the news.

Although this dataset isn't as ideal as data compiled directly from testing hundreds of thousands of endpoints across the internet, it does represent a sample of real-world API weaknesses.

Some potential  issues with applying this data include bug bounty program  incentivizes certain types of findings over others.

Bug bounty programs attract participants that represent a small sample of the APIs that are actually out in the wild.

Newsworthy incidents often leave security researchers without specific technical details.

Obviously newsworthy incidents do not include all of the breaches and security incidents that are not reported or publicized.

That being the case, there are lessons to be learned and risks to be aware of based on bug bounty, writeups, and publicized security incidents.

If you are interested in learning more about the sources, belows a list of common websites to dive deeper into bug bounty research.

In addition to these, attached to this module is a JSON extract from PentesterLand that contains all documented API writeups.

PentesterLand writeup compilation, HackerOne hack activity, Awesome Bugbounty writeups, all the links are in the content below.

Also, in the course content is a list of some of the most newsworthy API incidents in the last five years, including data breaches and leaks from the USPS, Optus, T-Mobile, and Toyota.

The OWASP API Security Top 10 list contains common groups of the most critical security risks to be on the lookout for based on these sources.

The OWASP API security risks are associated with references to external sources.

These sources include CWEs, or Common Weakness Enumeration, other OAS projects, and the National Institute of Standards and Technology, or NIST Guidance.

Most of the references involve CWE.

CWEs are a list of common software and hardware vulnerabilities developed by the community and hosted by MITRE.

Each CWE is identified by a unique identifier or CWEID.

This identifier can be used to refer back to a specific vulnerability.

Check out the full table of external sources in the course material below.

Understanding the external sources and how they're associated with a given OWASP API Security Top 10 risk will help provide you with additional insight.

Throughout the course external sources will be provided for the OWASP API Security Top 10 risks.

These resources will be provided to you to help you dive in as deep as you'd like into the topic of API security.

We will dive deeper into these  in later modules.

In the next section, we'll go over the updates to the top 10 list from 2019 to 2023.

Since the release of the OWASP API Security Top 10 in 2019, API usage has grown.

API related data breaches have continued and new API technologies have emerged.

All of this has played a role in the need for an updated version of the API security project's Top 10 list.

Since the 2019 Top 10, several events have demonstrated the importance of keeping the list updated and relevant.

API attacks are consistently on the rise.

Akamai reported seeing nearly 114 million API attacks in a single day in 2021.

The global API market value was valued at 2.2 billion in 2021, and was predicted to reach 41.5 by 2031.

That's a 20 times growth rate, in 10 years.

In 2022, Postman had over 46 million Postman collections, and GitHub had 3 million API related repos.

APIs continue to be rapidly adopted and the financial stakes continue to climb.

The OWASP API Security Project updated the Top 10 list to address some of the changes in the attack trends that have emerged since the previous version.

Inon Shkedy, OWASP API Security Project Leader, stated that the OWASP API Top 10 2023 version is different from the 2019 version.

"We aspire to follow the security trends that are relevant to APIs and have been developed in recent years.

If you try to hack or protect an API that was developed five years ago, it would make more sense to refer to the 2019 list." At a high level, when you compare the Top 10 from 2019 to 2023, you see that two previous risks were removed from the list, three remained exactly the same, four were updated, and five of the 2023 are new.

The two items that were removed included Injection and Insufficient Logging and Monitoring.

These two risks were not completely mitigated and resolved, but the importance of new emerging risks pushed them beyond the Top 10.

Logging and Monitoring is a classic OWASP Top 10 risk, but it is not an item that is represented in breaches or disclosed bug bounties.

Injection attacks are still around and many web APIs are still susceptible, but the adoption of web application firewalls and implementation of other mitigation techniques has reduced the occurrence of notable API injection.

There were three categories that remained on the list.

Broken Object Level Authorization or BOLA, Broken Function Level Authorization, or BFLA, and Security Misconfiguration.

BOLA and BFLA are still among the most common API risks and account for many of the breaches in bug bounty disclosures.

APIs continue to have severe issues when it comes to authorization risk.

The Security Misconfiguration category contains a wide range of possible misconfigurations that can plague APIs.

In other words, this category is unlikely to leave the Top 10 because it is a catchall for many API vulnerabilities.

Four categories were renamed.

The renaming of these categories helped simplify the risk categories and bring additional focus to the issue at hand.

Broken User Authentication has now become Broken Authentication.

This simplification has done away with User and now brings additional attention to the API authentication as a whole process.

Improper Assets Management has become Improper Inventory Management.

This change was likely made to better align with industry terminology and to cover a wider range of resources.

The term Assets might only refer to tangible items valued by an organization while the term Inventory could refer to a wider set of resources.

There were a total of five categories that were added to the OWASP API Security Top 10 2023 that were not on the 2019 version.

Server Side Request Forgery and Unsafe Consumption of APIs are completely new and did not have previous representation on the 2019 OWASP API Security Top 10 list.

Server Side Request Forgery was represented on the 2021 OWASP Top 10 list and was added to that list based on survey results rather than by incident occurrence.

The remaining new risk categories included Broken Object Property Level Authorization, or BOPLA, Unrestricted Resource Consumption, and Unrestricted Access to Sensitive Business Flows, each containing elements from the 2019 list.

For example, BOPLA is a combination of Excessive Data Exposure and Mass Assignment, and we will dive deeper into each of these later in the course.

Paired with each OWASP API security risk category are Risk Ratings.

The risk ratings were based on the OWASP risk rating methodology.

The project now refers to the OWASP risk rating framework.

In the written course content, there is a table demonstrating the risk ratings used for the OWASP API security project from the OWASP API Security Top 10 2019 pdf.

Any of these factors could significantly affect the overall likelihood of an attacker finding and exploiting a particular vulnerability.

This rating does not take into account the actual impact on a specific business.

The risk score must be determined by the given organization, as the project team states.

The purpose of the OWASP API Security Top 10 is not to do this risk analysis for you.

In other words, the purpose of the OWASP API Security Top 10 was not to perform a specific risk analysis for a given organization, but to provide a guideline for organizations to consider risk factors.

In the course content, you can see a table containing the changes to the 2019 and 2023 risk ratings.

The classic equation for risk is likelihood multiplied by impact with each risk score.

The OWASP API Security Project team has left the impact as a relative value to be determined by the business.

In addition, the project team includes a note along with these scores that the likelihood of these scores is not taken into account.

What we are left with are values that represent overall exploitability, including complexity, exploitability, weakness prevalence, weakness detectability, and technical impact.

Note that the overall score does not equate to a risk score because significant factors such as business impact and likelihood are not accounted for.

API1:2023 Broken Object Level Authorization, or BOLA, is one of the most prevalent and severe vulnerabilities for APIs.

BOLA vulnerabilities occur when an API provider does not have sufficient controls in place to enforce authorization.

In other words, API users should only have access to sensitive resources that belong to them.

When BOLA is present, an attacker will be able to access the sensitive data of other users.

The OWASP attack vector description states: "Attackers can exploit API endpoints that are vulnerable to a broken object level authorization by manipulating the ID of an object that is sent within the request.

Object IDs can be anything from sequential integers, UUIDs or generic strings.

Regardless of the data type, they're easy to identify in the request target, either through the path or a query string parameter request headers, or even as a part of the request payload." The OWASP security weakness description states: "This has been the most common and impactful attack on APIs.

Authorization and access control mechanisms in modern web applications are complex and widespread.

Even if the application implements a proper infrastructure for authorization checks, developers might forget to use these checks before accessing a sensitive object.

Access controlled detection is not typically amenable to automated static or dynamic testing." The OWASP impact description states: "Unauthorized access can result in data disclosure to unauthorized parties, data loss or data manipulation.

Unauthorized access to objects can also lead to full account takeover." If an API endpoint has insufficient access controls, it will not perform checks to ensure users can only access their own resources.

When these controls are missing, User A will be able to obtain User B's resources via API requests.

APIs use some sort of value like names or numbers to identify various objects.

When an attacker discovers an API's resource ID, they will attempt to obtain the resources when unauthenticated or authenticated as a different user.

For instance, imagine that an authenticated user Bruce sends a GET request to https://herohospital.com/api/v3/users?id=2727 and receives a JSON response back with his data, this poses no problem.

Bruce should be able to access Bruce's own information.

However, if Bruce is able to access another user's information, then a BOLA vulnerability would be present.

This weakness can be tested by using other resource IDs in place of 2727.

Say Bruce is able to obtain information about another user by sending a request to: https://herohospital.com/api/v3/users?id=2728, and receives a response about Harvey Dent and his dissociative identity disorder, then there would be a problem.

Assuming that Bruce is still using his authorization to access this data, this would be a clear indication that the API is vulnerable to BOLA.

BOLA isn't always as simple as this example because there's flexibility in how resources are provisioned and requested from one API to the next.

The written course content contains several examples of how API resources may be requested and attacked.

In these examples, tests can be performed by replacing the bolded resource IDs with other numbers or words.

Of course, in POST request, the resource could also be requested in the POST body.

If User A can successfully access the information of any other user, then there's a vulnerability present.

BOLA vulnerabilities are the most common API vulnerabilities and are easily exploitable and require a low amount of technical skills in order to discover these.

BOLA can present itself in many forms depending on how resources are organized.

As you can see in the written course, content resources can be organized by a user, by group, or by a combination of both.

In all of these instances, only those with the proper permission should be allowed to retrieve their resources.

The OWASP preventative measures state: In order to improve API security, it is important to implement robust authorization controls.

These controls should consider user policies and role-based access control hierarchies.

The primary focus should be to ensure that authenticated users only have access to resources they are authorized to have access to.

Using less predictable resource IDs can increase the challenge of a user or attacker guessing the resource ID of other users.

Developers should perform tests that specifically test for authorization controls.

Implement a proper authorization mechanism that relies on the user policies and hierarchy.

Use the authorization mechanism to check if the logged in user has access to perform the requested action on the record in every function that uses an input from the client to access the record in the database.

Prefer the use of random and unpredictable values, such as GUIDS for records IDs.

Write tests to evaluate the vulnerability of the authorization mechanism.

Do not deploy changes that make the tests fail.

Check out the written course content for additional resources about BOLA.

API2:2023, Broken Authentication, refers to any weakness within the API authentication process.

All APIs that contain sensitive information should have some mechanism to authenticate users.

Authentication is the process that is used to verify the identity of an API user.

Whether that is a person, device, or system.

In other words, authentication is the process of verifying that an entity is who that entity claims to be.

This verification process is normally done with the use of a username and password combination, a token and or multifactor authentication.

Authentication related vulnerabilities typically occur when an API provider either doesn't implement a strong authentication mechanism or implements an authentication process incorrectly.

The OWASP Attack Vector description for this states that "The authentication mechanism is an easy target for attackers since it's exposed to everyone.

Although more advanced technical skills may be required to exploit some authentication issues, exploitation tools are generally available." The OWASP Security Weakness description states "Software and security engineers' misconceptions regarding authentication, boundaries and inherent implementation complexity make authentication issues prevalent.

Methodologies of detecting broken authentication are available and easy to create." The OWASP Impacts Description states "Attackers can gain complete control of other users' accounts in the system, read their personal data, and perform sensitive actions on their behalf.

Systems are unlikely to be able to distinguish attackers actions from legitimate user ones." Broken Authentication continues to be a significant security issue due to poor password policies, weak authentication mechanisms, and misconfigurations.

API authentication is a complex process that is commonly found with most APIs and is necessarily exposed.

The impact of Broken Authentication can lead to an attacker taking control of user accounts, compromising personal data, and conducting sensitive actions like editing someone else's healthcare data.

The authentication process is often one of the first lines of defense for APIs, and when this mechanism is vulnerable, it can lead to a data breach.

A weak password policy does not sufficiently protect user accounts by enforcing strong password creation and management.

This allows users to create simple passwords, allows brute force attempts against user accounts, and allows users to change their password without asking for password confirmation.

Also allowing users to change their email without asking for password confirmation.

Weak password policies also disclose tokens or passwords in the URL.

It has a lack of authentication for sensitive requests.

And in regards to GraphQL queries, weak password policies would allow for many authentication attempts within a single request.

Credential stuffing is a type of attack against authentication where a large number of username and password combinations are attempted.

Credentials used in these types of attacks are typically collected from data breaches.

This sort of attack allows users to brute force many different username and password combinations without restrictions.

Predictable tokens refers to any token obtained through a weak token generation authentication process.

Weak tokens can easily be guessed, deduced, or calculated by an attacker.

This would be an issue if an API is using incremental or guessable tokens for IDs.

JWTs are commonly used for API authentication and authorization processes.

JWT stands for JSON Web Token.

JWTs provide developers with the flexibility to customize which algorithm is used for signing the token, the key and secret that is used and the information used in the payload.

This customization allows for plenty of room for security misconfigurations to occur.

These include API providers that accept unsigned JWT tokens, API providers that do not check JWT expirations, API providers that disclose sensitive information within the encoded JWT payload, and if the JWT is signed with a weak key.

API authentication can be a complex system that includes several processes with a lot of room for failure.

A couple decades ago, security expert Bruce Schneier said, "the future of digital systems is complexity, and complexity is the worst enemy of security." As we know from the six constraints of REST APIs, RESTful APIs are designed to be stateless.

To be stateless the API providers shouldn't need to remember the consumer from one request to another.

For this constraint to work, APIs often require users to undergo a registration process to obtain a unique token.

The token that is generated is then used in subsequent requests for authentication and authorization.

As a consequence, the registration process used to obtain an API token, the token handling, and the system that generates the token could all have their own set of weaknesses if the token generation process doesn't rely on a high level of randomness, or entropy, there's a chance that an attacker will be able to create their own token or hijack another user's token.

The other authentication processes that could have their own set of vulnerabilities include aspects of the registration system, like password reset and multifactor authentication features.

For example, imagine a password reset feature requiring you to provide an email address and a six digit code to reset your password.

While if the API allowed you to make as many requests as you wanted, you'd only have to make 1 million requests in order to guess the code and reset any user's password.

A four digit code would require only 10,000 requests.

As it states in the OWASP Preventative Measures, make sure you know all the possible flows to authenticate to the API.

Ask your engineers what flows you missed.

Read about your authentication mechanisms.

Make sure you understand what and how they are used.

OAuth is not authentication and neither are API keys.

Don't reinvent the wheel in authentication, token generation or password storage, use the standards.

Credential recovery and forgot password endpoints should be treated as login endpoints in terms of brute force, rate-limiting and lockout protections.

Require re-authentication for sensitive operations, including changing the account on our email address and multifactor phone number.

Use the OWASP API Authentication Cheat Sheet.

You can find that in the written content.

Where possible implement multifactor authentication.

Implement anti-brute force mechanisms to mitigate credential stuffing, dictionary attacks, and brute force attacks on your authentication endpoints.

This mechanism should be stricter than the regular rate limiting mechanisms on your APIs.

Implement account lockout capture mechanisms to prevent brute force attacks against specific users.

Implement weak-password checks.

API keys should not be used for authentication.

They should only be used for API client authentication.

Check out the written course content for additional resources about Broken Authentication.

API3:2023 Broken Object Property Level Authorization, or BOPLA, is a combination of two items from the 2019 OWASP API Security Top 10: Excessive Data Exposure and Mass Assignment.

Excessive Data Exposure takes place when an API provider responds to a request with an entire data object.

Usually an API provider will filter out  the data object down to what is being requested.

When the data object is shared without being filtered, there is an increased risk of exposing sensitive information.

Mass Assignment is a weakness that allows for user input to alter sensitive object properties.

If, for example, an API uses a special property to create admin accounts, only authorized users should be able to make requests that successfully alter those administrative properties.

If there are no restrictions in place, then an attacker would be able to elevate their privileges and perform administrative actions by altering those properties.

Both of these vulnerabilities involved issues with object property authorization, so they're combined under the new title of Broken Object Property Level Authorization.

As it states in the OWASP Attack Vector description: APIs tend to expose endpoints that return all objects properties.

This is particularly valid for REST APIs.

For other protocols such as GraphQL, it may require  crafted requests to specify which properties should be returned.

Identifying these additional properties that can be manipulated requires more effort, but there are a few automated tools available to assist in this task.

The OWASP Security Weakness description states in inspecting API responses is enough to identify sensitive information in returned objects, representations.

Fuzzing is usually used to identify additional hidden properties.

Whether they can be changed is a matter of crafting an API request and analyzing the response.

Side effect analysis may be required if the target property is not returned in the API response.

The OWASP Impacts Description states unauthorized access to private or sensitive object properties may result in data disclosure, data loss, or data corruption.

Under certain circumstances, unauthorized access to object properties can lead to privilege as escalation or partial to full account takeover.

As previously stated, Broken Object Property Level Authorization, or BOPLA, is a combination of Mass Assignment  and Excessive Data Exposure.

In the 2023 release notes, the security project states that these two vulnerabilities were combined focusing on the common root cause, object, property level authorization, validation failures.

The OWASP API Security project also states an API endpoint is vulnerable if either the API endpoint exposes properties of an object that are considered sensitive and should not be read by the user, which is an Excessive Data Exposure, or the API endpoint allows a user to change, add, or delete the value of a sensitive object's property, which the user should not be able to access, which is Mass Assignment.

Excessive Data Exposure is when an API endpoint responds with more information than is needed to fulfill a request.

This often occurs in cases when the provider expects the API consumer to filter results.

When a consumer requests specific information, the provider might respond with all sorts of information, assuming the consumer will then remove any data they don't need from the response.

When this vulnerability is present, it can be the equivalent of asking someone for their name and having them respond with their name, date of birth, email address, phone number, and the identification of every other person they know.

For example, if an API consumer requests information for their user account and receives information about other user accounts as well, the API is exposing excessive data.

Check out the written content for an example of an excessive data exposure vulnerability.

Excessive Data Exposure is an API vulnerability that is very difficult to detect with automated scanners.

In addition, this vulnerability will often bypass every security control in place to protect sensitive information and hand sensitive data to an attacker simply because they use the API.

To detect excessive data exposure API providers must test API endpoints and review the information sent in the response.

Mass Assignment occurs when an API consumer includes more parameters in its request than the application intended, and the application adds these parameters to code variables or internal objects.

In this situation, a consumer may be able to edit object properties or escalate the privileges.

For example, an application might have an account update functionality that the user should use only to update their username, password, and address.

If the consumer can include additional parameters in the request related to their account, such as the account privilege level, or sensitive information like an account balance, and the application accepts those parameters without checking them against the whitelist of permitted actions, the consumer could take advantage of this weakness to change these values.

Imagine an API is called to create an account with parameters for user and password.

The user could be hapi_hacker, password could be GreatPassword123.

While reading the API documentation regarding the account creation process, an attacker could discover that there's an additional property, which is an admin that the API provider uses to create administrative accounts.

An attacker could add this to a request and set the value to "true".

If the API does not sanitize the request input, it is vulnerable to Mass Assignment and attacker could use the request to create their own admin account.

On the backend the vulnerable web app will add the key value attribute {“isAdmin”: true} to the user object, and make the user the equivalent of an administrator for that application.

The OWASP Preventative Measures state when exposing an object using an API endpoint, always make sure that the user should have access to the object properties you expose.

Avoid using generic methods such as to_json() and to_string().

Instead, cherry-pick specific object properties you specifically want to return.

If possible, avoid using functions that automatically bind to client's input into code variables, internal objects or object properties.

Allow changes only to the object's properties that should be updated by the client.

Implement a schema based response validation mechanism as an extra layer of security.

As part of this mechanism, define and enforce data returned by all API methods.

Keep return data structures to the bare minimum according to the business functional requirements for the endpoint.

Check out the written course content for additional resources about BOPLA.

API4:2023 Unrestricted Resource Consumption is an API issue where the provider of the API does not have safeguards in place to prevent excessive use of their API.

When there are no restrictions for resource consumption, the API provider could become a victim of a denial of service, attack, or experience, unnecessary financial costs.

Unrestricted Resource Consumption is an updated version of API4:2019, Lack of Resources and Rate Limiting.

The OWASP Attack Vector description states exploitation requires simple API requests.

Multiple concurrent requests can be performed from a single local computer or by cloud computing resources.

Most of the automated tools available are designed to cause denial of service via high loads of traffic impacting API service rate.

The OWASP Security Weakness description states it's common to find APIs that do not limit client interactions or resource consumption.

Crafted API requests such as those, including parameters that control the number of resources to be returned and performing response status, time length analysis, should allow identification of the issue.

The same is valid for batched operations, although threat agents don't have visibility over costs impact, this can be inferred based on the service provider's business.

OWASP Impacts Description states exploitation can lead to denial of service due to resource starvation, but it can also lead to operational cost increase, such as those related due to the infrastructure due to higher CPU demand, increasing cloud storage needs, etc.

The OWASP API Security project states an API is vulnerable if at least one of the following limits is missing or set inappropriately, either too low or too high.

Execution timeouts, maximum allocable memory, maximum number of file descriptors, maximum number of processes, maximum upload file size number of operations to perform in a single API client request with things like GraphQL batching, number of records per page to return in a single request response, and third party service provider spending limit.

Every API request has a technical and financial cost when API providers do not enforce limitations on resource consumption, there's an increased risk of denial of service, distributed denial of service, unnecessary financial costs, and degradation of the quality of service to other users.

In addition rate limiting plays an important role in the monetization and availability of APIs.

Many API providers monetize their APIs by limiting requests and allowing paid customers to request more information.

RapidAPI, for example, allows some API providers to also have infrastructure that automatically scales with the number of API requests.

In these cases, an unlimited number of requests would lead to a significant and easily preventable increase in infrastructure costs.

The OWASP Preventative Measures states Docker makes it easy to limit memory, CPU, number of restarts, file descriptors and processes.

Implement a limit on how often a client can call the API within a defined timeframe.

Notify the client when the limit is exceeded by providing the limit number and the time at which the limit will be reset.

Add proper server side validation for query string and request body parameters, specifically the one that controls the number of records to be returned in the response.

Define and enforce maximum size of data on all incoming parameters and payloads, such as maximum length for strings and maximum number of elements in arrays.

Check out the written course content for additional resources about Unrestricted Resource Consumption.

API5:2023, Broken Function Level Authorization, or BFLA, is a vulnerability where API functions have insufficient access controls.

Where BOLA is about access to data, BFLA is about altering or deleting that data.

In addition, a vulnerable API would allow an attacker to perform actions of other roles, including administrative actions.

To drive the point home, a fintech API susceptible to BOLA would allow an attacker the ability to see what is in the bank account of another user, while the same API vulnerable to BFLA would allow an attacker to transfer funds from other users accounts to their own.

The OWASP Attack Vector description states "exploitation requires the attacker to send legitimate API calls to an API endpoint that they should not have access to as an anonymous user or regular non privileged user.

exposed endpoints will be easily exploited." The OWASP Security Weakness description states "authorization checks for a function or resource are usually managed via configuration or code level.

Implementing proper checks can be a confusing task since modern applications can contain many types of roles, groups, and complex user hierarchies.

It's easier to discover these flaws in APIs since APIs are more structured, and accessing different functions is more predictable." The OWASP Impacts Description states "such flaws allow attackers to access unauthorized functionality.

Administrative functions are key targets for this type of attack and may lead to data disclosure, data loss, or data corruption.

Ultimately, it may lead to service disruption." Broken Function Level Authorization, or BFLA, is a vulnerability where a user of one privilege level can use the API functionality of a different user, user group, or another privilege level.

API providers will often have different privilege levels for different types of accounts, such as public users, merchants, partners, vendors, administrators, and so on.

BFLA can be exploited for unauthorized use of lateral functions or a similarly privileged group, or it could be exploited for privilege escalation, where an attacker can use the functions of a more privileged group.

Particularly interesting API functions to access include those that deal with sensitive information, resources that belong to another group, and administrative functionality, like user account management.

If an API has different privilege levels, it may use different endpoints to perform those privileged actions.

For example, a bank may use /{userid}/account/balance as an endpoint for a user wishing to access their account information, and then use /admin/account/{userid} as an endpoint for an administrator that needs to access user account information.

If the application does not have access controls implemented correctly, an attacker will be able to perform administrative actions and perform an account takeover.

An API won't always use administrative endpoints for administrative functionality.

Instead, the functionality could be based on different HTTP request methods like GET, POST, PUT, and DELETE.

If a provider doesn't restrict the HTTP methods, or verbs, an attacker can use simply making an unauthorized request with a different method, could indicate a BFLA vulnerability.

When testing for BFLA, look for any functionality that an attacker could use to their advantage.

These functions include, but are not limited to, altering user accounts, deleting user resources, and gaining access to restricted endpoints.

For example, if an API gave partners the ability to add new users to the partner group, but did not restrict this functionality to the specific group, any user could add themselves to any group.

Moreover, if an attacker added themselves to a group, there's a good chance that there'll be able to access that group's sensitive resources.

Take a look at the written course content for an example of a BFLA attack.

The OWASP Preventative Measures state "your application should have a consistent and easy to analyze authorization module that is invoked from all your business functions.

Frequently, such protection is provided by one or more components external to the application code.

The enforcement mechanisms should deny all access by default, requiring explicit grants to specific roles for access to every function.

Review your API endpoints against function level authorization flaws, while keeping in mind the business logic of the application and group's hierarchy.

Make sure that all of your administrative controllers inherit from an administrative abstract controller that implements authorization checks based on the user's group or role.

Make sure that administrative functions inside a regular controller implement authorization checks based on the user's group and role." Check out the written course content for additional resources about Broken Function Level Authorization.

API6:2023, Unrestricted Access to Sensitive Business Flows represents the risk of an attacker being able to identify and exploit API driven workflows.

If vulnerable an attacker will be able to leverage an organization's API request structure to obstruct other users.

This obstruction could come in the form of spamming other users, depleting the stock of highly sought after items, or preventing other users from using expected application functionality.

This is a new addition to the 2023 top 10 list.

The OWASP Attack Vector description states "exploitation usually involves understanding the business model backed by the API, finding sensitive business flows, and automating access to these flows, causing harm to the business." The Security Weakness description states "lack of a holistic view of the API in order to fully support business requirements tends to contribute to the prevalence of this issue.

Attackers manually identify what resources or endpoints are involved in the target workflow and how they work together.

If mitigation mechanisms are already in place, attackers need to find a way to bypass them." The OWASP Impacts Description states "in general, technical impact is not expected.

Exploitation might hurt the business in different ways.

For example, prevalent legitimate users from purchasing a product or lead to an inflation in the internal economy of a game.

Regarding APIs, a flow is a series of requests and responses that lead to an operation.

If, for example, a purchase flow for a web application does not restrict access to a purchase process, then a scalper could automate requests to instantly drain the stock of an item down to nothing.

This is where mechanisms like a completely automated public Turing test to tell computers and humans apart, or better known as CAPTCHA, comes into play.

If a flow has a capture mechanism that requires human interaction, then the automated request could be interrupted and slow down automated purchasing.

Check out the written course material for an example API flow used to help build a notification bot for the PS5.

Customers and or scalpers competing to purchase the PS5 would use API flows to either complete purchases as soon as new stock was available or alert upon stock updates.

In the example, an API flow was used to automatically check for stock updates and send out email alerts.

The OWASP Preventative Measures state the mitigation planning should be done in two layers, business and engineering.

Business should identify the business flows that might harm the business if they are excessively used.

Engineering should choose the right protection mechanism to mitigate the business risk.

Some of the protection mechanisms are more simple while others are more difficult to implement.

The following methods are used to slow down automated threats.

Device fingerprinting.

Deny service to unexpected client devices, tends to make threat actors use more sophisticated solutions, thus more costly for them.

Next up is human detection using either CAPTCHA or more advanced biometric solutions.

Non human patterns.

Analyze the user flow to detect non human patterns.

For example, the user accessed the add to cart and complete purchase functions in less than one second.

Consider blocking IP addresses of Tor exit nodes and well known proxies.

Secure and limit access to APIs that are consumed directly by machines.

They tend to be an easy target for attackers because they often don't implement all the required protection mechanisms.

Check out the written course content for additional resources about unrestricted access to sensitive business flows.

API7:2023, Server Side Request Forgery is a vulnerability that takes place when a user is able to control the remote resources retrieved by an application.

An attacker can use an API to supply their own input in the form of a URL to control the remote resources that are retrieved by the targeted server.

An attacker could supply URLs that expose private data, scan the target's internal network, or compromise the target through remote code execution.

SSRF is also number 10 on the 2021 OWASP Top 10 List and is a growing threat to APIs.

The OWASP Attack Vector description states "exploitation requires the attacker to find an API endpoint that accesses a URI that's provided by the client.

In general, basic SSRF, when the response is returned by the attacker, is easier to exploit than blind SSRF, in which the attacker has no feedback on whether or not the attack was successful." The OWASP Security Weakness description states "modern concepts in application development encourages developers to access URIs provided by the client.

Lack of, or improper validation of such URIs are common issues.

Regular API requests and response analysis will be required to detect the issue.

When the response is not returned, detecting the vulnerability requires more effort and creativity." The OWASP Impacts Description states "successful exploitation might lead to internal services enumeration, information disclosure, bypassing firewalls, or other security mechanisms.

In some cases, it can lead to denial of service or the server being used as a proxy to hide malicious activities." SSRF is a vulnerability that takes place when an application retrieves remote resources without validating user input.

When an attacker has control over the resources a server requests, then they can gain access to sensitive data, or worse, completely compromise a vulnerable host.

The impact of this vulnerability is that an attacker would be able to leverage a target server to perform and process requests that they supply.

Note that  bug bounty payouts for SSRF are driven based on the impact that can be demonstrated with a proof of concept.

The higher the demonstrated impact, the higher the bounty.

There are two general types of SSRF that are worth noting.

In-Band SSRF and Out-of-Band SSRF, also known as Blind SSRF.

In-Band SSRF means that the server responds with the resources specified by the end user.

If the attacker specifies a payload such as google.com to a server with an In-Band SSRF vulnerability, the server would make the request to google.com and then respond to the attacker with information served from google.com.

Blind SSRF takes place when the attacker supplies a URL and the server makes the request, but the server does not send the information back from that specified URL to the attacker.

In the case of blind SSRF, an attacker would need control over a web server that would capture the request from the target as proof that they were able to force the server to make this request.

In the course In-Band SSRF example, an attacker makes a request that includes a URL.

That will be used to update the stock of an item in the store.

The attacker is able to replace that item stock URL with a local host URL to a directory with a password.

The server is vulnerable and provides the password back to the attacker.

Blind SSRF takes place when a vulnerable server performs a request from user input, but does not send back the response to the attacker indicating a successful attack.

In other words, the victim server makes the request to the URL specified by the attacker, but the attacker does not receive a direct message back from the victim server.

In this case, to know if the request was made, an attacker will need to have some control over the web server that is specified in the attack.

For examples and demonstrations of In-Band and Out-of-Band SSRF attacks check out the written course material.

The OWASP Preventative Measure states "isolate the resource fetching mechanism in your network.

Usually these features are aimed to retrieve remote resources and not internal ones.

Whenever possible, use allow lists of remote origins users are expected to download resources from, such as Google Drive or Gravatar, URL schemes and ports, accepted media types for a given functionality.

Disable HTTP redirections.

Use a well tested and maintained URL parser to avoid issues caused by URL parsing inconsistencies.

Validate and sanitize all client supplied input data.

Do not send raw responses to clients." Check out the written course content for additional resources about SSRF.

API8:2023, Security Misconfiguration represents a catch-all for many vulnerabilities related to the systems that host APIs.

When an API's security is misconfigured, it can be detrimental to the confidentiality, integrity, and availability of the API provider's data.

Due to the wide variety of flaws that could exist, the impacts of an exploited security misconfiguration can range from information disclosure to data breach.

The OWASP Attack Vector description states "attackers will often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system." The OWASP Security Weakness description states "security misconfiguration can happen at any level of the API stack from the network level to the application level.

Automated tools are available to detect and exploit misconfiguration such as unnecessary services or legacy options." The OWASP Impacts Description states "security misconfigurations can not only expose sensitive user data, but also system details that can lead to full server compromise." Security misconfigurations include all the mistakes that API providers can make within the supporting systems of an API.

Security misconfigurations are really a set of weaknesses that include misconfigured headers, misconfigured transit encryption, the use of default accounts, the acceptance of unnecessary HTTP methods, a lack of input sanitization, and verbose error messaging.

For example, if the API supporting security configuration reveals an unpatched vulnerability.

There's a chance that an attacker could leverage a published exploit to easily pwn the API and its systems.

A lack of input sanitization could allow attackers to upload malicious payloads to the server.

APIs often play a key role in automating processes, so imagine being able to upload payloads that the server automatically processes into a format that could be remotely executed or executed by an unsuspecting end user.

For example, if an upload endpoint was used to pass uploaded files to a web directory, then it could allow the upload of a script.

Navigating to the URL where the file is located could launch the script resulting in direct shell access to the web server.

Additionally, a lack of input sanitization can lead to unexpected behavior on the part of the application.

API providers use headers to provide the consumer with instructions for handling the response and security requirements.

Misconfigured headers can result in sensitive information disclosure, downgrade attacks, and cross site scripting attacks.

Many API providers will use additional services alongside their API to enhance API related metrics or to improve security.

It's fairly common that those additional services will add headers to requests for metrics and perhaps as some level of assurance to the consumer.

The X-Powered-By header reveals back end technology.

Headers like this one often advertise the exact supporting service and its version.

An attacker could use information like this to search for exploits published for that version of software.

The X-XSS-Protection header is exactly what it sounds like, a header that's meant to prevent cross-site scripting (XSS) attacks.

Cross site scripting is a common type of injection vulnerability where an attacker could insert scripts into a web page and trick end users into clicking on malicious links.

A X-XSS-Protection header with a value of 0 indicates no protections in place, and a value of 1 indicates that the protection is turned on.

This header and others like it, clearly reveals whether or not a security control is in place.

The X-Response-Time header is middleware that provides the usage metrics.

In this example, in the written course material, its value represents 566 milliseconds.

But if the API isn't configured properly, this header can function as a side channel used to reveal existing resources.

If the X-Response-Time header has a consistent response time for non existing records, for example, but increases its response time for certain other records that actually exist, this could be an indication to an attacker that they've come across these files.

Say, for instance, an attacker can determine that a bogus account like /user/account/thisdefinitelydoesnotexist has an average response time of 25 milliseconds.

The attacker can know that their existing account is /user/account/1021, which receives an X-Response-Time of 510 milliseconds.

An attacker could then send requests brute forcing account numbers and review the results and see which account numbers resulted in drastically increased response times.

Any API providing sensitive information to consumers should use Transport Layer Security to encrypt the data even if the API is only provided internally, privately, or at a partner level.

Transport Layer Security, the protocol that encrypts HTTPS traffic, is one of the most basic ways to ensure that API requests and responses are protected when being passed across a network.

Misconfigured or missing transit encryption can cause API users to pass sensitive API information in clear text across networks, in which case an attacker could capture the responses and requests with a Man-in-the-Middle (MITM) and read them plainly.

They would simply have to  intercept the network traffic with a network protocol analyzer like Wireshark to see the information being communicated between a consumer and a provider.

When a service uses default accounts or credentials, and the defaults are known, an attacker can use those credentials to assume the role of that account.

This could allow them to gain access to sensitive information or administrative functionality and potentially lead to a compromise of the supporting systems.

Lastly, if an API provider allows unnecessary HTTP methods, there's an increased risk that the application won't handle these methods properly or will result in sensitive information disclosure.

Out of all the vulnerabilities covered on the OWASP Top 10, API8:2023 Security Misconfiguration is one of the only ones that can be detected by web application vulnerability scanners.

Automated scanners like BurpSuite, Nessus, Qualys, OWASP, ZAP, and Nikto will automatically check responses from the web server to determine the version information, headers, cookies, transit encryption configuration, and parameters to see if expected security measures are missing.

Security misconfigurations can also be checked manually if you know what you're looking for, by inspecting the headers, SSL certificate, cookies, and parameters.

The OWASP Preventative Measures states the API lifecycle should include: repeatable hardening process leading to a fast and easy deployment of a properly locked out environment, a task to review and update configurations across the entire API stack.

The review should include orchestration files, API components and cloud services and automated process to continuously assess the effectiveness of the configuration and settings in all environments.

Furthermore, ensure that all API communications from the client to the API server And any downstream upstream components happen over an encrypted communication channel, regardless of whether it is an internal or public facing API.

Be specific about which HTTP verbs each API can be accessed by.

All other HTTP verbs should be disabled.

API's expecting to be accessed from browser based clients should at least implement a proper Cross Origin Resource Sharing (CORS) policy.

Include applicable security headers, restrict incoming content types/data formats to those that meet the business functional requirements.

Ensure all servers in the HTTP server chain process incoming requests in a uniform manner to avoid desync issues.

Where applicable, define and enforce all API response payload schemas, including error responses to prevent exception traces and other valuable information from being sent back to an attacker.

Check out the written course content for additional resources about API security misconfigurations.

API9:2023, Improper Inventory Management represents the risks involved with exposing non production and unsupported API versions.

When this is present, the non production and unsupported versions of the API are often not protected by the same security rigor as the production versions.

This makes improper inventory management a gateway to other API security vulnerabilities.

The OWASP Attack Vector description states "Threat agents usually get unauthorized access through old API versions or endpoints left running unpatched and using weaker security requirements.

Alternatively, they may get access to sensitive data through a third party with whom there's no reason to share data with." The OWASP Security Weakness description states "Outdated documentation makes it more difficult to find and or fix vulnerabilities.

Lack of assets, inventory, and retirement strategies leads to running unpatched systems, resulting in leakage of sensitive data.

It's common to find unnecessarily exposed API hosts because of modern concepts like microservices, which makes applications easy to deploy and independent.

Simple Google Dorking, DNS enumeration, or using specialized search engines for various types of servers connected to the internet will be enough to discover targets." The OWASP Impacts description states "Attackers can gain access to sensitive data or even take over the server.

Sometimes different API version deployments are connected to the same database with real data.

Threat agents may exploit deprecated endpoints available to in old API versions to get access to administrative functions or exploit known vulnerabilities." Improper Inventory Management takes place when an organization exposes APIs that are unsupported or still in development.

As with any software, old API versions are more likely to contain vulnerabilities because they are no longer being patched and upgraded.

Likewise, APIs that are still being developed and are typically not as secure as their production API counterparts.

Improper inventory management can lead to other vulnerabilities such as excessive data exposure, information disclosure, mass assignment, improper rate limiting, and API injection.

For attackers, this means that discovering an improper inventory management vulnerability is only the first step toward further exploitation of an API.

Detecting Improper Inventory Management can be tested by using outdated API documentation, changelogs, and version history on repositories.

For example, if an organization's API documentation has not been updated along with the API's endpoints, it could contain references to portions of the API that are no longer supported.

Organizations often include versioning information in their endpoints names to distinguish between older and newer versions.

Such as /v1/, /v2/, or /v3/ and so on.

APIs still in development often use paths such as /alpha/, /beta/, /test/, /uat/ and /demo/.

If you know that an API is now using apiv3.org/admin, but a part of the API documentation refers to apiv1.org/admin, you could try testing different endpoints to see if apiv1 or apiv2 are still active.

Additionally, the organization's change log may disclose the reasons why v1 was updated or retired.

If an attacker has access to v1, they can test those for weaknesses.

Outside of using documentation, an attacker could discover improper inventory vulnerabilities through the use of guessing, fuzzing, or brute forcing requests.

Testing for improper assets management is all about discovering unsupported and non production versions of an API.

API providers will often update services and the newer version of the API in a variety of ways, such as api.target.com/v3, or /api/v2/accounts, or /api/v3/accounts.

API versioning could also be maintained as a header.

So you could see something like Accept: version=2.0, or Accept api-version=3.

In addition, versioning could also be set within a query parameter or the request body.

So you could see /api/accounts?ver=2.

Or POST to API accounts with the versioning equals 1.0.

Non production versions of an API include any version of the API that was not meant for end user consumption.

Non production versions could include api.test.target.com, beta.api.com, /api/private, /api/partner or /api/test.

In these instances, earlier versions of the API may no longer be patched or updated since the older versions lack this support.

They may expose the API to additional vulnerabilities and lead an attacker to a path that can be used to compromise the provider's data.

The OWASP Preventative Measures states inventory all API hosts and document important aspects of each one of them, focusing on the API environment, such as production, staging, test or development, who should have network access to the host, such as public, internal or partners and the API version inventory integrated services and document important aspects, such as their role in the system, what data is exchanged and its sensitivity.

Document all aspects of your API, such as authentication, errors, redirects, rate limiting, cross origin resource sharing, CORS policy, and endpoints, including their parameters, requests, and responses.

Generate documentation automatically by adopting open standards.

Include the documentation built in your CI/CD pipeline.

Make API documentation available to those authorized to use the API.

Use external protection measures, such as an API security firewall, for all exposed versions of your APIs.

Not just for the current production versions.

Avoid using production data with non production API deployments.

If this is unavoidable, these endpoints should get the same security treatment as the production ones.

When newer versions of the API include security improvements, perform risks analysis, risk analysis to make the decision of the mitigation actions required for the older version.

For example, whether it is possible to backport the improvements without breaking API compatibility, or you need to take the older version, but quickly enforce all clients to move to the latest version.

For additional resources about improper inventory management, check out the written course materials.

API10:2023, Unsafe Consumption of APIs is the only item on the Top 10 list that focuses less on the risks of being an API provider and more on the risks of being an API consumer.

Unsafe consumption is really a trust issue.

When an application is consuming the data of a third party API, it should treat those with a similar trust to user input.

By that, I mean there should be little to no trust.

So data consumed from third party API should be treated with similar security standards as end user supplied input.

If a third party API provider is compromised, then that insecure API connection back to the consumer becomes a new attack vector for the attacker to leverage.

In the case of an insecure API connection, that could mean the complete compromise of organizations insecurely consuming data from that API provider.

The OWASP Attack Vector description states "exploiting this issue requires attackers to identify and potentially compromise other APIs or services the target API is integrated with.

Usually this information is not publicly available or the integrated API or service is not easily exploitable." The OWASP Security Weakness description states "developers tend to trust and not verify the endpoints that interact with external or third party APIs relying on weaker security requirements such as those regarding transport security, authentication, authorization, and input validation and sanitization.

Attackers need to identify services the target API interacts with or integrates with and eventually compromise them." The OWASP Impacts description states "the impact varies according to what the target API does with pooled data.

Successful exploitation may lead to sensitive information exposure to unauthorized actors, many kinds of injections, or denial of service." Most of the 2023 API Security Top 10 is about APIs and the API provider.

An API can often serve as the path of least resistance for an attacker.

So if an attacker compromises a third party API provider, then that third party's connection to other businesses can become an additional attack vector.

If that API is over an unencrypted connection, then an attacker would be able to capture sensitive data in clear text.

If that third party API isn't held to similar security standards as internet facing APIs, then it could also be vulnerable to injection, authorization, authentication and other compromising attacks.

The OWASP Preventative Measure states when evaluating service providers assess their API security posture.

Ensure all API interactions happen over a secure communication channel.

Always validate and properly sanitize data received from integrated APIs before using it.

Maintain and allow a list of well known locations integrated APIs may redirect yours to.

Do not blindly follow redirects.

For additional Resources about unsafe consumption of APIs, check out the written course materials.

Injection vulnerabilities have plagued web applications for over two decades.

They take place when an attacker can send commands that are executed by the systems that support the web application.

The most common forms of injection attacks are SQL injection, cross site scripting, and operating system command injection.

APIs are yet another attack vector for these critical attacks to be communicated from an attacker to the supporting system, supporting databases and systems.

The OWASP 2019 Attack Vector description states, "attackers will feed the API with malicious data through whatever injection vectors are available, such as direct input parameters, integrated services, expecting it to be sent to an interpreter." The OWASP 2019 Security Weakness description states, "injection flaws are very common and are often found in SQL, LDAP, or NoSQL queries, OS commands, XML parsers, and ORM.

These flaws are easy to discover when reviewing the source code.

Attackers can use scanners and fuzzers to find these." The OWASP 2019 Impacts Description states, Injection can lead to information disclosure and data loss and may also lead to denial of service or complete host takeover.

Injection flaws exist when a request is passed to the API supporting infrastructure and the API provider doesn't filter the input to remove unwanted characters.

As a result, the infrastructure might treat the data from the request as code and run it.

When this sort of flaw is present, an attacker will be able to conduct injection attacks like SQL injection, NoSQL injection, and system command injection.

When these injection attacks are successful, the API delivers an unsanitized payload directly to the operating system running the application or a query to its database.

As a result, if an attacker sends a payload containing SQL commands to a vulnerable API that uses a SQL database, the API will pass the commands to the database, which will process and perform the commands.

The same will happen with vulnerable NoSQL databases and affected systems.

Verbose error messaging, HTTP response codes, and unexpected API behavior can all be clues to an attacker and will be an indication that they have discovered an injection flaw.

Say, for example, an attacker were to send OR1 00 DAS as an address in an account registration process.

The API may pass that payload directly back to the back end SQL database, where the or 1 equals 0 statement, which would fail as 1 does not equal 0, causing a SQL error.

An error in the backend database could show up as a response to the consumer.

In this case, the attacker, who's the consumer, might receive a response like, Error equals you have an error in your SQL syntax.

But, any response directly from the database or the supporting system will serve as a clear indicator that there's likely an injection vulnerability.

Injection vulnerabilities are often complemented by other weaknesses like poor input sanitization.

Injection flaws can have serious impacts by providing an attacker with the ability to manipulate an API supporting system or database.

Finding injection flaws requires diligently testing API endpoints and paying attention to how the API responds, then crafting requests that attempt to manipulate the backend systems.

Injection attacks have been around for decades, so there are many standard security controls that can be used to protect API providers from them.

The OWASP 2019 Preventative Measures states, Preventing injection requires keeping data separate from commands and queries.

Perform data validation using a single trustworthy and actively maintained library.

Validate, filter, and sanitize all client provided data or other data coming from integrated systems.

Special characters should be escaped using the specific syntax for the target interpreter.

Prefer a safe API that provides parameterized interface.

Always limit the number of returned records to prevent mass disclosure in case of injection.

Validate incoming data using sufficient filters to only allow valid values for each input parameter.

Define data types and strict patterns for all string parameters.

For additional resources about API injection, check out the written course content.

Logging and Monitoring are a necessary and important layer of API security.

In order to detect an attack against an API, an organization must have monitoring in place.

Without sufficient logging and monitoring, an API provider is operating in the dark, and API attacks are guaranteed to go unnoticed until it's far too late.

The OWASP 2019 Attack Vector description states, "Attackers take advantage of a lack of logging and monitoring to abuse systems without being noticed." The OWASP 2019 Security Weakness description states, "Without logging and monitoring, or insufficient logging and monitoring, it is almost impossible to track suspicious activities and respond to them in a timely fashion." The OWASP 2019 Impacts description states, "Without visibility over ongoing malicious activities, attackers have plenty of time to fully compromise systems.

Logs can reveal patterns in API usage and can be used as evidence to understand how an API is abused.

Logging and monitoring provide an audit trail of activities and are often required for compliance purposes." An important part of logging is to ensure that the logs have integrity and cannot be altered by an attacker.

Monitoring an API will help providers detect suspicious activities and anomalous user behavior.

This helps providers be able to take action to thwart attacks.

Logging and monitoring are essential for improving API performance and security.

The OWASP 2019 Preventative Measures states, log all failed authentication attempts, denied access, and input validation errors.

Logs should be written using a format suited to be consumed by a log management solution and should include enough detail to identify the malicious actor.

Logs should be handled as sensitive data and their integrity should be guaranteed at rest and transit.

Configure a monitoring system to continuously monitor the infrastructure network and API functioning.

Use a SIEM system to aggregate and manage logs from all components of the API stack and hosts.

Configure custom dashboards and alerts enabling suspicious activities to be detected and responded to earlier.

For additional resources about insufficient logging and monitoring, check out the written course content.

Business logic vulnerabilities are weaknesses within applications that are unique to the policies and features of a given API provider.

The exploitation of business logic takes place when an attacker leverages misplaced trust or features of an application against the API.

Identifying business logic vulnerabilities can be challenging due to the unique nature of each business.

The impact of these vulnerabilities can range based on the severity of the vulnerable policy or feature.

My attack vector description for this Business logic vulnerabilities are unique to each application and exploit the normal intended functioning of an application's business processes.

They often require specific knowledge of the application's functionality and the flow of transactions or data.

Since these vulnerabilities are specific to the business logic of each application, there's no one size fits all approach to identifying them.

My security weakness description states, business logic vulnerabilities arise when the assumptions and constraints of a given business process aren't properly enforced in the application's control structures.

This allows users to manipulate the application's functionality to achieve outcomes that are detrimental to the business.

These weaknesses typically occur when developers fail to anticipate the various ways that an application's features can be misused or when they don't consider the wider context of the business rules.

This is often due to a lack of comprehensive understanding of the application's business logic, a lack of input validation, or incomplete function level authorization checks.

My impacts description states Business logic vulnerabilities can cause a variety of technical impacts depending on the specific flaw in the systems involved.

These impacts can range from unauthorized access to data or functionality to a total bypass of system controls.

Business logic vulnerabilities, also known as business logic flaws, or BLFs, are intended features of an application that attackers can use maliciously.

For example, if an API has an upload feature that instructs users to only upload certain encoded payloads, but doesn't actually validate those encoded payloads, a user could upload any file as long as it was encoded.

This would allow end users to upload and potentially execute arbitrary code, including malicious payloads.

Vulnerabilities of this sort normally come about from an assumption that API consumers will follow directions, be trustworthy, or only use the API in a certain way.

In those cases, the organization essentially depends on trust as a security control by expecting the consumer to act benevolently.

Unfortunately, even good natured API consumers make mistakes that could lead to a compromise of the application.

The Experian partner API leak in 2021 was a great example of an API trust failure.

A certain Experian partner was authorized to use Experian's API to perform credit checks, but the partner added the API's credit check functionality to their web application and inadvertently exposed all partner level requests to users.

This request could be intercepted when using the partner's web application, and if it included a name and address, the Experian API would respond with the individual's credit score and credit risk factors.

One of the leading causes of this business logic vulnerability was that the Experian trusted the partner to not expose the API.

Another problem with trust is that credentials like API keys, tokens, and passwords are constantly being stolen and leaked.

When a trusted consumer's credentials are stolen, the consumer can become a wolf in sheep's clothing and wreak havoc.

Without strong technical controls in place, business logic vulnerabilities can often have the most significant impact leading to exploitation and compromise.

An API's documentation can be a telltale sign of a business logic vulnerability.

Statements like the following should be indications of potential business logic flaws.

Only use feature x to perform function y.

Do not do x with endpoint y.

Only admins should perform request X.

These statements may indicate that the API provider is trusting that end users won't do any of the discouraged actions as instructed.

An attacker will easily disobey such requests to test for the presence of technical security controls.

Another business logic vulnerability comes about when developers assume that consumers will exclusively use a browser to interact with the web application and won't capture API requests that take place behind the scenes.

All it takes to exploit this sort of weakness is for an attacker to intercept requests and alter the API request before it is sent to the provider.

This would allow the attacker to capture shared API keys or use parameters that could negatively impact the security of the application.

As an example, consider a web app authentication portal that a user normally would employ to authenticate to their account.

Say the web application issued an API authentication request that included the username and password along with a query parameter, multi factor equals true.

There's a chance that an attacker could bypass the multi factor authentication by simply altering the parameter to false.

Testing for business logic flaws can be challenging because each business is unique.

Automated scanners will have a difficult time detecting these issues, as the flaws are part of the API's intended use.

You must understand how the business and API operate, and then consider how an attacker could use these features to their advantage.

One method of testing for business logic flaws is to study the application's business logic with an adversarial mindset and try breaking any assumptions that have been made.

My preventative measures for business logic flaws include the following.

Use a threat modeling approach.

Understand the business processes and workflows your API supports.

Identify the potential threats, weaknesses, and risks during the design phase that can help to uncover and mitigate business logic vulnerabilities.

Reduce or remove trust relationships with users, systems, or components.

Business logic vulnerabilities can be used to exploit these trust relationships leading to a broader impact.

Regular training can help developers to understand and avoid business logic vulnerabilities.

Training should cover secure coding practices, common vulnerabilities, and how to identify potential issues during design and coding phases.

Implement a bug bounty program, third party penetration testing, or responsible disclosure policy.

This allows security researchers who are a step removed from the design and delivery of an application to disclose vulnerabilities they discover in APIs.

For additional resources about business logic vulnerabilities, check out the written course material.

And that wraps up the OWASP API security top 10 and beyond course.

Hope you enjoyed it.

And if you'd like to earn a badge and certificate for this course, please enroll at apisecuniversity.com, take the quizzes, and we'll be happy to issue your cert.

And while you're there, be sure to check out our other courses, including API Pen Testing, API Security Fundamentals, and more.

We also host many webinars with API experts across industries, disciplines, and geographies.

You'll see these listed on our website and on our YouTube channel.

Please subscribe.

Thanks for watching, and hope to see you again soon.