Slides for my webinar "API Security Fundamentals". They cover
👉 𝐎𝐖𝐀𝐒𝐏’𝐬 𝐭𝐨𝐩 𝟏𝟎 API security vulnerabilities with suggestions on how to avoid them, including the 2019 and the 2023 versions.
👉 API authorization and authentication using 𝐎𝐀𝐮𝐭𝐡 and 𝐎𝐈𝐃𝐂
👉 How certain 𝐀𝐏𝐈 𝐝𝐞𝐬𝐢𝐠𝐧𝐬 expose vulnerabilities and how to prevent them
👉 APIs sit within a wider system and therefore API security requires a 𝐡𝐨𝐥𝐢𝐬𝐭𝐢𝐜 𝐚𝐩𝐩𝐫𝐨𝐚𝐜𝐡. I’ll talk about elements “around the API” that also need to be protected
👉 automating API 𝐬𝐞𝐜𝐮𝐫𝐢𝐭𝐲 𝐭𝐞𝐬𝐭𝐢𝐧𝐠
4. Agenda
OWASP Top 10 API Security Vulnerabilities (2019 and 2023)
Open Authorization
OpenID Connect
Vulnerable API design
Vulnerabilities around the API
Automating API security testing
5. OWASP Top 10 API Vulnerabilities (2023)
1. Broken Object Level Authorization
2. Broken Authentication
3. Broken Object Property Level Authorization
4. Unrestricted Resource Consumption
5. Broken Function Level Authorization
6. Server-Side Request Forgery
7. Security Misconfiguration
8. Lack of Protection from Automated Threats
9. Improper Assets Management
10. Unsafe Consumption of APIs
6. Broken Object Level Authorization (BOLA)
BOLA happens when attackers get access to information that
belongs to other users. This type of attack is commonly done
by manipulating resource URIs on the API. For example, if our
API has a /blog/{blogId} endpoint, an attacker can play with
different IDs to try and get access to different resources (APIs
with predictable IDs, such as integers, are more vulnerable).
8. Broken Authentication
When user authentication is incorrectly implemented, like weak
passwords or token signatures, weak token validation (such as
lack of signature, expiry date, or audience validation, or
allowing to set “alg” to “none”), lack rate-limiting on the login
endpoints, and so on.
10. Broken Object Property Level Authorization
Broken Object Property Level Authorization brings together
two different vulnerabilities from the 2019 edition: “Excessive
Data Exposure” and “Mass Assignment”. The main idea is
allowing a malicious user access object properties that they
shouldn't be able to read or change.
13. Unrestricted Resource Consumption
This vulnerability implies lack of rate-limiting and the inability
to detect malicious activity. Malicious users can exploit this
vulnerability to launch a DDoS attack, to impact the service
provider’s billing, or to perform brute force attacks that bypass
authorization (by launching requests with different tokens and
so on).
15. Broken Function Level Authorization
Most APIs and applications have a concept of user groups and
functions. Broken Function Level Authorization happens when
a malicious user can bypass the constraints of their user group.
17. Server-Side Request Forgery
Most APIs and applications have a concept of user groups and
functions. Broken Some APIs allow users to send URLs from
which our service must retrieve a resource (for example to
retrieve a user profile photo), or as part of some configuration
(for example to configure a webhook). A malicious user may
use this feature to include malicious URLs, or to obtain
information from the system.
18. Security Misconfiguration
Security misconfiguration refers to improper configuration at
any level of the stack, including infrastructure, configuration
management, or application configuration. Some examples are
missing TLS, leaking stack trace in error responses, CORS
misconfiguration, exposing more HTTP methods than are
needed, missing security patches and updates, improperly
configured cloud permissions, etc.
20. Lack of Protection from Automated Threats
Means malicious users can harm the business model through
the API. It involves knowledge of the underlying business
model behind the API.
22. Improper Assets Management
This refers to management of API, servers, and resources.
When we roll out a new version of the API, it’s important to
ensure deprecation of the older versions, especially if the
newer versions come with security improvements. It’s also
important to keep API documentation up to date, as obsolete
documentation makes it difficult to monitor and test the APIs.
We also need to ensure that non-production servers aren’t
accessible to unauthorized users.
24. Unsafe Consumption of APIs
Most APIs use third-party integrations, for example for
authentication and authorization, for mapping and
geolocation, for emailing, and so on. Most of the time, we tend
to trust data that comes from third-party applications, and we
don’t subject it to validation and sanitisation. This is a mistake,
since an attacker can inject malicious code into the third-party
application.
25. Injection (2019)
Injection happens when an attacker injects malicious code
through the API, such as SQL/noSQL injection queries that get
executed in the database, or command injection statements
that get executed in the server. An attacker can leverage any
input field in the API to launch an injection attack, including
URL query and path parameters, request payloads, header
values, field values in a JWT, and so on.
33. JSON Web Tokens (JWTs)
JSON Web Tokens (JWT, pronounced ‘JOT’) are JSON documents that contain
information about a user. We call the properties of a JWT claims. Two types:
ID tokens
Access tokens
35. OpenID Connect (OIDC)
OpenID Connect (OIDC) is an open authentication protocol built on top of
OAuth that allows users to authenticate on a website using a third-party
provider.
37. Vulnerable API design
Unbound arrays
Leaking objects
Free-form strings
Integer IDs
Exposing server-side properties in user input
Flexible schemas with unknown properties
Too many IDs
Improper pagination
Unrestricted filters
Very flexible schemas with optional parameters
38. Vulnerabilities around the API
Protect the database
Restrict outbound traffic
Collect detailed logs and actively monitor them
Use a WAF
Rate-limit requests
Restrict resource consumption
Use safe packages and libraries