1.
$ whoami
• I’m Jose
• Consultant, author, instructor
• Author of Microservice APIs
• Founder of microapis.io
@JoseHaroPeralta
@microapis

2.
Connect with me!
 Twitter: @JoseHaroPeralta
 GitHub: @abunuwas
 Newsletter: https://microapis.substack.com
 LinkedIn: https://www.linkedin.com/in/jose-haro-
peralta/

3.
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

4.
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

5.
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).

6.
Broken Object
Level
Authorization
(BOLA)

7.
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.

8.
Broken
Authentication

9.
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.

10.
Broken Object
Property Level
Authorization

11.
Broken Object
Property Level
Authorization

12.
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).

13.
Unrestricted
Resource
Consumption

14.
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.

15.
Broken
Function Level
Authorization

16.
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.

17.
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.

18.
Security
Misconfiguration

19.
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.

20.
Lack of
Protection
from
Automated
Threats

21.
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.

22.
Improper
Assets
Management

23.
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.

24.
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.

25.
Injection (2019)

26.
Authentication vs
Authorization
Authentication is the
process of verifying a user
identity, while authorization
is the process of verifying
that they have access to
something.

27.
Open Authorization (OAuth)
OAuth is a standard for access delegation.
 Resource owner
 Resource server
 Client
 Authorization server

28.
OAuth flows:
Authorization
code flow

29.
OAuth
flows:
PKCE flow

30.
OAuth flows:
Client
credentials
flow

31.
OAuth
flows:
Refresh
Token
Flow

32.
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

33.
Structure
of a JWT

34.
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.

35.
OpenID
Connect
(OIDC)

36.
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

37.
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

38.
Automating API security testing with fencer

39.
Thanks for listening!
Twitter: @JoseHaroPeralta
GitHub: @abunuwas
Newsletter: https://microapis.substack.com
LinkedIn: https://www.linkedin.com/in/jose-haro-peralta/