Enhancing Security:

The Need for an API-Specific Risk Assessment

OWASP API Security Top 10

OWASP API Risk rating methodology

Standard Risk Methodology 1: Identifying a Risk Threat Agent Factor

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

5: Deciding What to Fix Business Impact

6: Customizing Risk Rating Model

OWASP API Risk Methodology

Likelihood Impact

Threat Agent Exploitability Weakness Prevalence Weakness detectability Technical Impact Business 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
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 limiting Average (2) Widespread (3) Easy (3) Moderate (2)
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-10 Insufficient logging and Average (2) Widespread (3) Difficult (1) Moderate (2)
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
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
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
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
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
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.
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.
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
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.
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.