OWASP API Risk rating methodology

Standard Risk Methodology 1: Identifying a Risk Threat Agent Factor

2: Factors for Estimating Vulnerability
Likelihood Factors
OWASP API Risk rating
Risk = Likelihood * Impact methodology 3: Factors for Estimating Impact
4: Determining Severity of the
Risk Technical Impact

5: Deciding What to Fix Business Impact

6: Customizing Risk Rating

OWASP API Risk Methodology Model

Likelihood Impact
Threat Exploitability Weakness Prevalence Weakness detectability Technical Business Impact
Agent Impact

API Specific Easy (3) Widespread (3) Easy (3) Severe (3) Business Specific

Financial Damage
Skill Level Average (2) Common (2) Average (2) Moderate (2) Reputational
Motive Damage
Opportunity Non-Compliance
Size Difficult (3) Difficult (1) Difficult (1) Minor (1) Privacy Violation
C2 General
C2 General
 OWASP API Security Top 10
Assessment and categorisation of API security were done in two phase

First phase: Preparing the list, publicly available data about APIs security incidents were collected, reviewed, and categorized by a group of
security experts. Such data was collected from bug bounty platforms and vulnerability databases, within a one-year-old time frame. It was used for
statistical purposes.
Second phase: security practitioners with penetration testing experience were asked to compile their own Top 10 list.

OWASP API Security Top 10 2019 resulted from a consensus between statistical results from phase one, and the security practitioners' lists.
likelihood Iimpact
SI # Risk Threat Agent Exploitability Prevalence Detectability Technical Impact Business Impact
API-1 Broken object level authorization Easy (3) Widespread (3) Average (2) Severe (3)
API-2 Broken authentication Easy (3) Common (2) Average (2) Severe (3)
API-3 Excessive data exposure Easy (3) Common (2) Average (2) Moderate (2)
API-4 Lack of resources and rate Average (2) Widespread (3) Easy (3) Moderate (2)
limiting

API-5 Broken function level Easy (3) Common (2) Difficult (1) Moderate (2)
authorization

API-6 Mass assignment Average (2) Common (2) Average (2) Moderate (2)
API-7 Security misconfiguration Easy (3) Widespread (3) Easy (3) Moderate (2)
API-8 Injection Easy (3) Common (2) Easy (3) Severe (3)
API-9 Improper assets management Easy (3) Widespread (3) Average (2) Moderate (2)
API- Insufficient logging and Average (2) Widespread (3) Difficult (1) Moderate (2)
10
C2 General monitoring
 API-1: Broken object level authorization
What it is
Attackers substitute the ID of their own resource in the API call with an ID of a resource belonging to another user.
The lack of proper authorization checks allows attackers to access the specified resource. This attack is also known as
IDOR (Insecure Direct Object Reference).

Best practices

1. Implement authorization checks with user policies and

hierarchy
2. Don’t rely on IDs sent from client. Use IDs stored in
the session object instead.
3. Check authorization each time there is a client request
to access database

C2 General
 API-2 : Broken authentication
What it is
Poorly implemented API authentication allowing attackers to assume other users’ identities

Best practices

1. Check all possible ways to authenticate to all APIs

2. Password reset APIs and one-time links also allow users
to get authenticated and should be protected just as
seriously
3. Use standard authentication, token generation, password
storage, Multi-factor authentication
4. Use short-lived access tokens
5. Use stricter rate-limiting for authentication, implement
lockout policies and weak password check

C2 General
 API-3 : Excessive data exposure
What it is
The API may expose a lot more data than what the client legitimately needs, relying on the client to do the
filtering. If attackers go directly to the API, they have it all.

Best practices

1. Never rely on client to filter data

2. Review all responses and adapt responses to what
the API consumers really need
3. Define schemas of all the API responses
4. Don’t forget about error responses
5. Identify all the sensitive or PII info and justify its
use
6. Enforce response checks to prevent accidental data
and exception leaks

C2 General
 API-4 : Lack of resources and rate limiting
What it is
The API is not protected against an excessive amount of calls or payload sizes. Attackers can use this for Denial of
Service (DoS) and authentication flaws like brute force attacks.

Best practices

1. Rate limiting
2. Payload size limits
3. Rate limits specific to API methods, clients,
addresses
4. Checks on compression ratios
5. Limits on container resources

C2 General
 API-5 : Broken function level authorization

What it is
The API relies on the client to use user level or admin level APIs as appropriate. Attackers figure out the “hidden” admin
API methods and invoke them directly.

Best practices
1. Don’t rely on app to enforce admin access
2. Deny all access by default
3. Grant access based on specific roles
4. Properly design and test authorization

C2 General
 API-6 : Mass assignment
What it is

The API takes data that client provides and stores it without proper filtering for whitelisted properties. Attackers can
try to guess object properties or provide additional object properties in their requests, read the documentation, or
check out API endpoints for clues where to find the openings to modify properties they are not supposed to on the
data objects stored in the backend.
Best practices
• Do not automatically bind incoming data and internal
objects.
• Explicitly define all the parameters and payloads you
are expecting.
• Use the readOnly property set to true in object schemas
for all properties that can be retrieved through APIs but
should never be modified.
• Precisely define the schemas, types, and patterns you
will accept in requests at design time and enforce them
at runtime.

C2 General
 API7 : Security misconfiguration
What it is
Poor configuration of the API servers allows attackers to exploit them.

Best practices
1. Establish repeatable hardening and patching
processes.
2. Automate locating configuration flaws.
3. Disable unnecessary features.
4. Restrict administrative access.
5. Define and enforce all outputs, including
errors.

C2 General
 API-8: Injection
What it is
Attackers construct API calls that include SQL, NoSQL, LDAP, OS, or other commands that the API or the
backend behind it blindly executes.

Best practices
1. Never trust your API consumers, even if they
are internal.
2. Strictly define all input data, such as
schemas, types, and string patterns, and
enforce them at runtime.
3. Validate, filter, and sanitize all incoming
data.
4. Define, limit, and enforce API outputs to
prevent data leaks

C2 General
 API-9 : Improper assets management
What it is
Attackers find non-production versions of the API (for example, staging, testing, beta, or earlier versions) that are not as well
protected as the production API, and use those to launch their attacks.

Best practices
1. Keep an up-to-date inventory all API hosts.
2. Limit access to anything that should not be
public.
3. Limit access to production data, and segregate
access to production and non-production data.
4. Implement additional external controls, such as
API firewalls.
5. Properly retire old versions of APIs or backport
security fixes to them.
6. Implement strict authentication, redirects,
CORS, and so forth.

C2 General
 API-10 : Insufficient logging and monitoring
What it is
Lack of proper logging, monitoring, and alerting allows attacks and attackers go unnoticed.

Best practices
1. Log failed attempts, denied access, input
validation failures, or any failures in security policy
checks.
2. Ensure that logs are formatted so that other tools
can consume them as well.
3. Protect logs like highly sensitive information.
4. Include enough detail to identify attackers.
5. Avoid having sensitive data in logs — if you need
the information for debugging purposes, redact it
partially.
6. Integrate with SIEMs and other dashboards,
monitoring, and alerting tools.

C2 General