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.
