OWASP API Security Top 10 and Beyond!
Introduction to OWASP API Security Top 10
What is OWASP API Security Top 10?
Open Web Application Security Project (OWASP) - a non-profit organization help to improve application security, launched in 2001
OWASP API Security Top 10 - launched because of rapid gap in API security and almost applications uses API, compiled from news, breaches, API incidents, bug bounty platforms and mapped to external sources (CWE and NIST)
Updates to the API Security Top 10
Risk Ratings - based on OWASP rating methodology, these factors could significantly affect overall likelihood of an attacker finding and exploiting a particular vulnerability and does not impact the actual business
API1:2023 Broken Object Level Authorization
BOLA
BOLA - occurs when an API provider does not have sufficient control in place to enforce authorization, API users should only have access to sensitive resources that belong to them, if BOLA is present, the hackers can now have access to other users' sensitive data.
In BOLA User A can obtain User B's resources
OWASP Preventative Measures
Implement authorization with user policies and hierarchy
Verify users have access to the resources they're accessing
Use random object IDs where possible
Test APIs to identify any authorization vulnerabilities
API2:2023 Broken Authentication
Broken Authentication
Broken Authentication - refers to weakness within the API authentication process, all API that serves sensitive data needs a mechanism to authenticate users
Authentication - process that is used to verify the identity of an API user, process done with the use of username and password combination, token and MFA
Weak Password Policy
Allows simple passwords
Allows brute force attempts against users
Allows change of password without asking password confirmation
Allows change of email without asking password confirmation
Discloses token or password in URL
GraphQL queries allows many authentication requests in single request
Lacking authentication for sensitive requests
Credentials Stuffing - one of authentication attacks
Attack using number of username and password combinations
Credentials used in this attack are collected from data breaches
Allows bruteforce of many username and password combinations
Predictable Tokens
Tokens obtained through a weak token generation authentication process
Weak tokens can be easily guessed, deduced, or calculated by an attacker
Using incremental or guessable token IDs
Misconfigured JSON Web Tokens
JWTs commonly used for API authentication and authorization
Provides flexibility to customize algorithms used for signing the token, the key/secret that is used, and the information used in the payload
Security Misconfigurations:
API provider accepts unsigned JWT tokens
API provider does not check JWT expiration
API provider sensitive information within encoded JWT payload
JWT is signed with a weak key
API Authentication
REST requires APIs to be stateless
APIs, therefore, require users to register to acquire tokens
Token is used for future requests
Issues with Authentication
Insufficient token randomness (entropy)
Vulnerabilities in registration process
Password reset process
MFA features
OWASP Preventative Measures
Know all about possible flows to authenticate to the API
Understand your authentication mechanisms and how they are used - OAuth is not authentication, and neither the API keys
Use standards for authentication, token generation, or password storage
Treat credential recovery/forgot password endpoints as login endpoints in terms of brute force, rate limiting, and lockout protections
Require re-authentication for sensitive operations (e.g., changing the account owner email address/2FA phone number)
Use the OWASP Authentication cheatsheet
Implement MFA, where possible
Implement anti-brute force mechanisms to mitigate credential stuffing, dictionary attacks, and brute force attacks
Implement account lockout/captcha mechanisms to prevent brute force attacks against specific users
Implement weak-password checks
API keys should not be used for user authentication - they should only be used for API clients authentication
Additional Resources
API3:2023 Broken Object Property Level Authorization
Broken Object Property Level Authorization
BOPLA - combination of 2 items, excessive data exposure and mass assignment
Excessive Data Exposure - when API provider responds to a request with an entire data object
Mass Assignment - weakness that allows for user input to alter sensitive object
BOPLA Vulnerabilities
Excessive Data Exposure - exposes properties of an object that are considered sensitive, consumer is expected to filter results
Mass Assignment - API endpoint that allows user to change, add/or delete the value of a sensitive object's property , it also includes more parameters
Test for Data Exposure
Very difficult to detect with automated scanners
Bypasses every security control in place to protect sensitive information
Can deliver sensitive data to an attacker
API providers must test API endpoints and review information in response
OWASP Preventative Measures
Make sure users should have access to object's properties
Avoid using generic methods such as to_json() and to_string()
Avoid functions that automatically bind input into code variables, objects or properties
Only allow changes to object's properties that should be updated by the client
Implement response validation as added security measure
Define and enforce data returned by all API methods
Minimize data structures, according to business/functional requirements
Additional Resources
API4:2023 Unrestricted Resource Consumption
Unrestricted Resource Consumption
Unrestricted Resource Consumption - an API issue where the provider of the API does not have safeguards in place to prevent excessive use of their API
Sources of Vulnerability
Execution of timeouts
Max allocable memory
Max number of file descriptors
Max number of processes
Number of operations in single request
Number of records in single request
3rd party provider's spend limit
Summary
Every API request has technical and financial cost
Lack of controls increase risk of
DOS
Unnecessary financial cost
Degradation of service to users
OWASP Preventative Measures
Docker offers control for memory, CPU, restarts, file, descriptors, processes
Limit number of API calls within timeframe
Notify client when limit is exceeded
Add server-side validation for inputs
Define, enforce max size for inputs and payloads
Additional Resources
"Rate Limiting (Throttling)" - Security Strategies for Microservices-based Application Systems, NIST
API5:2023 Broken Function Level Authorization
Broken Function Level Authorization
Broken Function Level Authorization - where API functions has insufficient access controls, and also about altering and deleting data
BFLA Vulnerability
User can use functionality of another user
API provider cam have different privilege levels
Public users, merchants, partners, vendors, admins
Can be exploited for:
Unauthorized use of lateral functions
Privilege escalation
Targeted API functions-endpoints with:
Sensitive info
Resources that belong to another group
Account management
Different endpoints for privileged actions
/{userid}/account/balance - user account info
/admin/account/{userid} - administrator endpoint
Admin endpoint can be exploited if API has improper access controls
An admin can perform admin actions, account takeover
APIs don't always have admin endpoints
HTTP request methods can control access to functionality
E.g., GET, POST, PUT, and DELETE
Attack can exploit unrestricted methods to exploit API functionality
Testing for BFLA
Identify endpoints an attacker could use to their advantage
Altering user accounts
Deleting user resources
Gaining access to restricted endpoints
Here a DELETE method used in place of PUT, response: "This is an admin function. Try to access the admin API."
Attacker could target admin path with DELETE: /identify/api/v2/admin/videos/758, the admin path/method does not have authorization controls, this is a BFLA vulnerability
OWASP Preventative Measures
Have easy-to-analyze authorization module for all business functions
Deny all access by default, require explicit grants to each roles to every functions
Review functions against function level authorization flaws
Ensure admin controllers inherit from an administrative abstract controller that implements authorization checks based on the user's group/role
Ensure admin functions inside a regular controller implement authorization checks based on the user's group/role
Additional Resources
"A7: Missing Function Level Access Control", OWASP Top 10 2013
API6:2023 Unrestricted Access to Sensitive Business Flows
Unrestricted Access to Sensitive Business Flows
Unrestricted Access to Sensitive Business Flows - represents the risk of an attacker being able to identify and exploit API-driven workflow
OWASP Preventative Measures
Mitigation done in 2 layers:
Business - identify business flows that might harm the business if they are excessively used
Engineering - choose the right protection mechanisms to mitigate the business risk
Slow down automated threats
Device fingerprinting: deny service to unexpected client devices
Human detection: use captcha or advanced biometric solutions
Non-human patterns: analyze trafiice to detect non-human patterns
Consider blocking IP address of Tor exit nodes, well-known proxies
Secure and limit access to APIs consumed directly by machines
API7:2023 Server Side Request Forgery
SSRF
SSRF - vulnerability that takes place when a user is able to control the remote resources retrieved by an application
SSRF Summary
App retrieves remote resources without input validation
Attacker can control what resources a server requests
Allows attackers to access sensitive data, compromise host
Attacker leverages target server to process their requests
SSRF bug bounty payouts based on level of impact
OWASP Preventative Measures
Isolate the resource fetching mechanism in your network
Use allow lists
remote origins
URL schemes, ports
accepted media types
Disable HTTP redirections
Use URL parser
Validate and sanitize user inputs
Do not send raw responses to clients
API8:2023 Security Misconfiguration
Security Misconfiguration
Security Misconfiguration - all host APIs that is misconfigured can be detrimental to the CIA of the provider
Misconfiguration Examples
Misconfigured headers
Misconfigured transit encryption
Use of default accounts
Acceptance of unnecessary HTTP methods
Lack of input sanitization
Verbose error messaging
API Header Misconfiguration
API providers use headers for handling response and security requirements
Misconfigured headers can result to sensitive info disclosure, downgrade attacks and XSS
Many APIs use additional service to enhance metrics and security
X-Powered-By Header
Reveals backend technology
Often advertise the exact supporting service and its version
Useful to find exploits published for that version of software
X-XSS-Protection Header
Prevents XSS attacks
Common type of injection vulnerability
Insert scripts to trick end-users to click malicious links
Value of 0 indicates no protections, 1 indicates protection enabled
Header clearly reveals whether a security control is in place
X-Response-Time Header
Middleware that provides usage metric
If API isn't configured properly this header reveal existing resources
X-Response-Time may differ for existing vs non-existing records
Example:
/user/account/doesnotexist - response time 25.5ms
/user/account/123 (valid id) - response time 510ms
Transport Layer Security
APIs with sensitive info should use TLS
TLS is fundamental way to protect data communication
Misconfigured encryption can pass sensitive API info in cleartext
Attacker could capture the responses and requests MITM attack
Default Accounts and Credentials
Attacker can use default credentials
Could allow:
Access to sensitive info
Access to admin functionality
Potential lead to compromise of supporting systems
HTTP Methods
Unnecessary HTTP methods can increase risk
Application may not handle these methods properly
Potential disclosure of sensitive info
Testing for Misconfigurations
Can be detected by web app scanners
Automated scanners will check:
Version info
Headers
Cookies
Transit encryption configuration
Parameters
Can be checked manually
OWASP Preventative Measures
Repeatable hardening process for a properly locked down environment
Review and update configurations accross the entire API stack
Orchestration files
API components
Cloud services (e.g. bucket permissions)
Automated, continuous assessment of configuration/setting effectiveness
Communication of client and server should be encrypted
Specify what HTTP verbs API accepts, otherwise deny
APIs accessible from browser-based client should:
Implement CORS policy
Include applicable security headers
Restrict incoming content types/data format to those that meet requirements
Ensure all servers in the HTTP chain process incoming requests in uniform manner
Define, enforce all API responses to prevent exception traces and other valuable info
Additional Resources
API9:2023 Improper Inventory Management
Improper Inventory Management
Improper Inventory Management - represents the risks involved with exposing non-production and unsupported API versions
Summary
Exposes unsupported APIs
Old API versions are more likely to contain vulnerabilities
Can lead to other vulnerabilities
Excessive data exposure, info disclosure, mass assignment, improper rate-limiting, API injection
Detecting Improper Inventory
Test with outdated API documentation, changelogs and version history on repositories
Version information: /v1/, /v2/, /v3/
APIs in development paths: /alpha/, /beta/, /test/, /uat/, /demo/
Discovering Improper Inventory
Techniques: guessing, fuzzing, or brute force requests
Testing focuses on unsupported and non-production API versions
Typical new version paths
api.target.com/v3
/api/v2/accounts
/api/v3/accounts
/v2/accounts
API versioning could be also maintained as header:
Accept: version=2
Accept: api-version=3
Versioning can be set within query parameter or request body
/api/accounts?ver=2
Non-production API versions example:
api.test.target.com
api.uat.target.com
beta.api.com
/api/private
/api/partner
/api/test
OWASP Preventative Measures
Inventory, document all API hosts and the API versions
Inventory, document integrated services - role, data flow, sensitivity
Document API details: authentication, errors, redirects, rate limiting, CORS, endpoints (parameters, requests and responses)
Auto-generate documentation, and include in CI/CD
Make API documentation available to authorized consumers
User external API protection firewalls for all versions, not just the current
Avoid using production data with non-production API deployments
Perform risk analysis when publishing newer versions of APIs
Additional Resources
API10:2023 Unsafe Consumption of APIs
Unsafe Consumption of APIs
Unsafe Consumption of APIs - trust issues, when an app is consuming the data of third-party APIs it should treat those with a similar trust to user input
Summary
Most of API Top 10 focuses on API Provider
APIs often path of least resistance
If attacker compromises 3rd party API, then other business at risk
If API uses unencrypted connection then data exposed in clear text
3rd party APIs may have less stringent security standards
Could also be vulnerable to injection, authorization, other attacks
OWASP Preventative Measures
Assess API security of service providers
Ensure all API is encrypted
Always validate, sanitize data received 3rd party APIs
Do not blindly follow redirects
Additional Resources
Beyond the Top 10
Injection
Injection - when attacker is able to send commands that are executed by the systems that support web app, SQLi, XSS, Command Injection
Summary
Injections occur when APIs do not filter unwanted characters
Infrastructure might treat data from the request as code and run it
Enables: SQLi, NoSQLi, Command Injection
Example:
Attacker send SQL command to API
API passes the commands to the database and execute it
Clues: verbose error messaging, HTTP response codes, unexpected behavior
OWASP Preventative Measures
Perform data validation
Validate, filter, and sanitize all client-provided data
Escape all special characters
Prefer a safe API that provides a parameterized interface
Limit number returned records to prevent mass disclosure
Validate incoming data, only allow valid values
Defined data types and strict patterns for all string parameters
Additional Resources
Insufficient Logging and Monitoring
Insufficient Logging and Monitoring - in order to detect attack we need a monitoring mechanism in place
Summary
Logs reveal patterns in API usage, can also identify abuse
Logs provide audit trail of activities
Often required for compliance purposes
Ensure logs cannot be altered by attackers
Monitoring helps detect suspicious activities, anomalous behaviour
OWASP Preventative Measures
Log failed authentication, denied access, input validation errors
Write logs for a log management solution, include detail to identify malicious actor
Logs should be handled as sensitive data
Continuously monitor infrastructure, network and API functioning
Use an SIEM
Configure custom alerts to detect suspicious activities
Business Logic Flaws
Business Logic Flaws - weaknesses within app that are unique to the policies and features of a given API provider
Summary
BLF - are misuse/abuse of intended app functionality
Example, an API allows only upload certain encoded payloads
But does not validate encoded payloads
Allowing user upload any encoded file
Users to upload and execute arbitrary code
BLF come from assumption of API consumers will follow directions and only use API in certain way
Orgs rely so much in access control, expecting users acts normally
Even good-natured API consumers makes mistakes
BLF Example:
Experian API leak
Experian partner authorized to use their API to perform credit checks
Partner added the API's credit check functionality to their web app
Exposed all partner-level requests to users
Request could be intercepted, Experian API would respond with credit scores
Experian trusted the partner not to expose API
Credentials constantly leaked and stolen
Logic vulnerabilities have impact
Examine API documentation for signs of business logic vulnerabilities
Statements like:
"Only use feature X, to perform function Y"
"Do not do X with endpoint Y"
"Only admins should perform request X"
These statements may indicate reliance on trust
Attacker will disobey such requests and to test for technical security controls
Bypassing Web UIs
Cannot assume users will exclusively use a browser
Attacker can easily intercept requests and alter API request
This could allow attackers to capture share API keys or abuse parameters
Attackers could bypass MFA by altering the parameter
Preventative Measures
Use a threat modelling approach
Reduce or remove trust relationships
Train developers to avoid BLF
Implement a bug bounty program, third-party pentesting or a responsible disclosure policy
Last updated