DATASHEET

Protecting the Enterprise

OWASP API Security Top 10
Vulnerabilities

The OWASP Top 10 project has for a long time been the
standard list of top vulnerabilities to look for and mitigate in
the world of web applications. APIs represent a significantly
different set of threats, attack vectors, and security best
42Crunch’s ability to
practices for enterprises. That is why the OWASP commu-
secure both the CI/CD
nity launched a new classification of Top 10 vulnerabilities,
pipeline & the runtime
specific to API Security.
environment makes it a
42Crunch offers end-to-end protection for APIs with a compelling candidate
developer-first platform that enables continuous, automat- for any API security
ed and scalable API security. Enterprises do not have to rely project.
on security by obscurity, manually configured rules, or
hope that some anomaly detection can report an attack.
With 42Crunch, our platform automatically protects your RIK TURNER
APIs from the OWASP Top 10 API Security Vulnerabilities Principal Analyst
and many additional threats. OMDIA

1. BROKEN OBJECT LEVEL AUTHORIZATION

Attacker substitutes ID of their resource in API call with an ID of a resource belonging to another user.
Lack of proper authorization checks allows access. This attack is also known as IDOR (Insecure Direct
Object Reference).

• API call parameters use IDs of resourced accessed by the

API: /api/shop1/financial_details • Implement authorization checks with user policies and
HOW TO PREVENT

• Attackers replace the IDs of their resources with different hierarchy

USE CASES

ones, which they guessed: • Don’t rely on IDs sent from client. Use IDs stored in the
/api/shop2/financial_details session object instead.
• The API does not check permissions and lets the call • Check authorization each time there is a client request
through to access database
• Problem is aggravated if IDs can be enumerated: • Use random non-guessable IDs (UUIDs)
/api/123/financial_details
 2. BROKEN AUTHENTICATION
Poorly implemented API authentication allowing attackers to assume other users’ identities.

• Check all possible ways to authenticate to all APIs

• Unprotected APIs that are considered “internal”
• Password reset APIs and one-time links also allows users to
• Weak authentication not following industry best practices

HOW TO PREVENT
get authenticated and should be protected just as seriously
• Weak, not rotating API keys
USE CASES

• Use standard authentication, token generation, password

• Weak, plain text, encrypted, poorly hashed, shared/default
storage, Multi- factor authentication
passwords • Susceptible to brute force attacks and
• Use short-lived access tokens
credential stuffing
• Authenticate your apps (so you know who is talking
• Credentials and keys in URL
to you)
• Lack of access token validation (including JWT validation)
• Use stricter rate-limiting for authentication, implement
• Unsigned, weakly signed, non-expiring JWTs
lockout policies and weak password checks

3. EXCESSIVE DATA EXPOSURE

API exposing a lot more data than the client legitimately needs, relying on the client to do the filtering.
Attacker goes directly to the API and has it all.

• Never rely on client to filter data

HOW TO PREVENT
• Review all responses and adapt responses to what the
• APIs return full data objects as they are stored by the
API consumers really need
USE CASES

database
• Define schemas of all the API responses
• Client application shows only the data that user needs
• Don’t forget about error responses
to see
• Identify all the sensitive or PII info and justify its use
• Attacker calls the API directly and gets sensitive data
• Enforce response checks to prevent accidental data and
exception leaks

4. LACK OF RESOURCES & RATE LIMITING

API is not protected against an excessive amount of calls or payload sizes. Attackers use that for DoS and
brute force attacks.
HOW TO PREVENT

• Rate limiting
• Attacker overloading the API
USE CASES

• Payload size limits

• Excessive rate of requests
• Rate limits specific to API methods, clients, addresses
• Request or field sizes
• Checks on compression ratios
• “Zip bombs”
• Limits on container resources

Security the way it should be.

We use 42Crunch to improve the security posture of our APIs.

GLOBAL AUTOMOTIVE MANUFACTURER

 5. BROKEN FUNCTION LEVEL AUTHORIZATION
API relies on client to use user level or admin level APIs. Attacker figures out the “hidden” admin API
methods and invokes them directly.

Some administrative functions are exposed as APIs

HOW TO PREVENT
• Non-privileged users can access these functions if they • Don’t rely on app to enforce admin access
USE CASES

know how
• Deny all access by default
• Can be a matter of knowing the URL, using a different
• Grant access based on specific roles
verb or parameter
• Properly design and test authorization
/api/users/v1/user/myinfo
/api/admins/v1/users/all

6. MASS ASSIGNMENT

• API working with the data structures

• Received payload is blindly transformed into an object • Don’t automatically bind incoming data and internal objects

HOW TO PREVENT
and stored • Explicitly define all the parameters and payloads you are
USE CASES

NodeJS: expecting
var user = new User(req.body); • For object schemas, use the readOnly set to true for all
user.save(); properties that can be retrieved via APIs but should never be
Rails: modified
@user = User.new(params[:user])
• Precisely define at design time the schemas, types, patterns
• Attackers can guess the fields by looking at the GET you will accept in requests and enforce them at runtime
request data

7. SECURITY MISCONFIGURATION
Poor configuration of the API servers allows attackers to exploit them.

• Unpatched systems

HOW TO PREVENT
• Unprotected files and directories
• Repeatable hardening and patching processes
• Unhardened images
USE CASES

• Automated process to locate configuration flaws

• Missing, outdated, misconfigured TLS
• Disable unnecessary features
• Exposed storage or server management panels
• Restrict administrative access
• Missing CORS policy or security headers
• Define and enforce all outputs including errors
• Error messages with stack traces
• Unnecessary features enabled

8. INJECTION
Attacker constructs API calls that include SQL-, NoSQL-, LDAP-, OS- and other commands that the API
or backend behind it blindly executes.
HOW TO PREVENT

Attackers send malicious input to be forwarded

to an internal interpreter: . Never trust your API consumers, even if internal
USE CASES

• SQL, NoSQL • Strictly define all input data: schemas, types, string patterns
• LDAP - and enforce them at runtime
• OS commands • Validate, filter, sanitize all incoming data
. XML parsers • Define, limit, and enforce API outputs to prevent data leaks
• Object-Relational Mapping (ORM)
 9. IMPROPER ASSETS MANAGEMENT
Attacker finds non-production versions of the API: such as staging, testing, beta or earlier versions - that
are not as well protected, and uses those to launch the attack.

• DevOps, cloud, containers, K8s make having multiple

deployments easy (Dev, Test, Branches, Staging, Old . Inventory all API hosts

HOW TO PREVENT
versions) • Limit access to anything that should not be public
USE CASES

• Desire to maintain backward compatibility forces to leave • Limit access to production data. Segregate access to
old APIs running production and non-production data.
• Old or non-production versions are not properly maintained • Implement additional external controls such as API firewalls
• These endpoints still have access to production data • Properly retire old versions or backport security fixes
• Once authenticated with one endpoint, attacker may • Implement strict authentication, redirects, CORS, etc.
switch to the other

10. INSUFFICIENT LOGGING AND MONITORING

Lack of proper logging, monitoring, and alerting let attacks go unnoticed.

• Log failed attempts, denied access, input validation failures,

any failures in security policy checks
• Lack of logging, monitoring, alerting allow attackers to go

HOW TO PREVENT
• Ensure that logs are formatted to be consumable by other
unnoticed
tools
USE CASES

• Logs are not protected for integrity

• Protect logs as highly sensitive
• Logs are not integrated into Security Information and Event
• Include enough detail to identify attackers
Management (SIEM) systems
• Avoid having sensitive data in logs - If you need the
• Logs and alerts are poorly designed
information for debugging purposes, redact it partially.
• Companies rely on manual rather than automated systems
• Integrate with SIEMs and other dashboards, monitoring,
alerting tools

ABOUT 42CRUNCH
APIs are the core building block of every enterprise's digital
strategy, yet they are also the number one attack surface for
hackers. The time is right for a new approach to API security.
42Crunch offers the industry's only Developer-First API We meet the most rigorous
Security platform to empower your developers with a industry security standards.
shift-left approach to design and automate security into
your APIs. The platform's shield-right runtime enforcement
capability also provides security teams with full visibility and
control of security policy enforcement throughout the API
lifecycle. We contribute to
the community work on
San Francisco - Dublin - São Paulo - Montpellier - London the OpenAPI specification.

© 42Crunch.com 2021