API Pentesting
Recon & Fuzzing
Endpoint fuzzing (paths, parameters, headers)
Is HTTP (port 80) or encrypted traffic still enabled or
supported?
Test allowed HTTP methods (e.g., via OPTIONS)
Discover undocumented APIs
If /api/v1/<endpoint> try without v1 or try v2, v3, etc
Authentication
Broken Authentication:
Check if API for login or password reset/forgot
password allows user enumeration
Check if API permits credential stuffing where the
attacker uses brute force with a list of valid usernames
and passwords.
Check if API permits attackers to perform a brute force
attack on the same user account, without presenting
captcha/account lockout mechanism.
Check if API permits weak passwords.
Remove, modify or use an old or previously used (if
applicable) authentication/session token/API key, and
attempt to make an API call, The API may not validate
the authenticity of tokens/API Keys.
Check if API sends sensitive authentication info, such as
auth tokens, API Keys, and passwords in the URL/ via
GET request.
Check if API allows users to change their email address,
current password, or do any other sensitive operations
without asking for password confirmation.
Check if API that handles password reset returns the
OTP in the very same HTTP response. OTP must only be
sent to a previously registered contact info.
For OTP, check if endpoints that handles OTP has rate
limiting protection
For OTP, check if OTP has expiration and how long is it.
Check if API is vulnerable to common account take over
vulnerabilities, E.g. attacker supplies a valid username,
with no password, or with a space character as the
password, or with any incorrect password and verify if
API returned any valid JWT/ token).
Weak or predictable token patterns ( Sequencer is
helpful here)
For JWT test cases, check below. The general idea is
that we check if the API accepts unsigned/weakly
signed JWT tokens ({“alg”:”none”}). If symmetric key is
used such as HS256, try to bruteforce the key that was
used to sign the JWT (jwtool, Burp extension, Hashcat,
etc). Check if JWT doesn’t validate the JWT expiration
date ( or if it has a very long expiration date). Check for
excessive sensitive info in JWT payload.
Check if API uses plain text, non-encrypted, or weakly
hashed passwords (e.g. if using Authorization Basic
header).
Check if API uses weak encryption keys.
Authorization or Access Control Issues
BOLA / IDOR (Insecure Direct Object Reference) —
“BOLA — access to objects referenced by their ID such
as a user id or a GUID” — TCM Academy
BFLA (Broken Function Level Authorization) Example:
user-to-admin privilege escalation or ordering in
another user’s behalf. “BFLA — access to functionality
that you shouldn't have access to” — TCM Academy
Session Management
Session expiration behavior
Injection Attacks
SQL Injection or NoSQL Injection ( depending on what
backend DB is used, best to ask the client (if gray box
test) to lessen the payload/traffic we send (via sqlmap,
burp, etc)
Command Injection
XML External Entity (XXE) (Even if the HTTP Request
body of the API is JSON, using “Content Type
Converter” Burp extension, change the Content type to
XML. Check if request is successful, if yes and API
supports/process XML, consider testing for XXE and
similar vulnerabilities that are applicable to XML.
Cross-Site Scripting (XSS)
SSTI ( This also applies in API endpoints), if grey box
test, best to ask the app owner what is the templating
engine used by the app ( e.g. jinja2, twig, etc.
- BOPLA (Broken Object Property Level Authorization)
Excessive Data Exposure
Mass Assignment ( Param Miner is helpful here). Few
techniques for finding Mass Assignment: If app is
opensource, perform a source code review; If using
JWT, decode it and see the claims, then set these claims
on new user creations; Review the info returned by
endpoints; Attempt to fuzz it
Some scenario for Mass Assignment; when registering a
user, if there is some identifier or anything that pertains
to permission level, e.g. when registering, change
“user” to “admin” or “KYC non verified” to “KYC
verified”. Or if in registration endpoint, it has
- Logic & Resource Abuse
Business Logic Vulnerabilities
Race Conditions
File Upload Vulnerabilities
Unrestricted Resource Consumption
Other Common Web Misconfigurations that also
applies to API
SSRF (Server-Side Request Forgery)
Open Redirect
Server-Side Parameter Pollution
HTTP Host Header Attacks
HTTP Request Smuggling ( HTTP Request Smuggler is
helpful here)
CORS Misconfigurations
Check for Content-Type mismatch ( what's in the Accept
request header should be the same in the Content-Type
response header, if mismatch, can lead to XSS; e.g. if
Accept header is application/json; check if Content-Type
is also showing “application/json”.
Improper Error Handling / Stack Trace errors
Server or Software version disclosures
Directory listing is enabled?
Lack of Rate Limiting?
GraphQL-Specific Tests
Is introspection enabled?
Batch operations for brute-force or DoS
Apply all REST API test cases: access control, injection,
etc.
Cloud Storage
Check if the API or the Application itself is using a cloud
storage. e.g using Cloud_enum and review if there are
exposed buckets or blobs.
Missing Security Headers
Strict-Transport-Security (HSTS)
Content-Security-Policy (CSP)
X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
X-XSS-Protection