Authentication

Don't use Basic Auth. Use standard authentication instead (e.g. JWT, OAuth).
Don't reinvent the wheel in Authentication, token generation, password storage. Use the standards.
Use Max Retry and jail features in Login.
Use encryption on all sensitive data.

JWT (JSON Web Token)

Use a random complicated key (JWT Secret) to make brute forcing the token very hard.
Don't extract the algorithm from the header. Force the algorithm in the backend (HS256 or RS256).
Make token expiration (TTL, RTTL) as short as possible.
Don't store sensitive data in the JWT payload, it can be decoded easily. (jwt.io)

OAuth

Always validate redirect_uri server-side to allow only whitelisted URLs.

Always try to exchange for code and not tokens (don't allow response_type=token).
Use state parameter with a random hash to prevent CSRF on the OAuth authentication process.
Define the default scope, and validate scope parameters for each application.

Access

Limit requests (Throttling) to avoid DDoS / brute-force attacks.

Use HTTPS on server side to avoid MITM (Man in the Middle Attack).
Use HSTS header with SSL to avoid SSL Strip attack.
For private APIs, only allow access from whitelisted IPs/hosts.

Input

Use the proper HTTP method according to the operation: GET (read), POST (create), PUT/PATCH (replace/update), and DELE
Allowed if the requested method isn't appropriate for the requested resource.
Validate content-type on request Accept header (Content Negotiation) to allow only your supported format (e.g. application
Acceptable response if not matched.
Validate content-type of posted data as you accept (e.g. application/x-www-form-urlencoded, multipart/form-data, applica
Validate user input to avoid common vulnerabilities (e.g. XSS, SQL-Injection, Remote Code Execution, etc.).
Don't use any sensitive data (credentials, Passwords, security tokens, or API keys) in the URL, but use standard Authorization
Use an API Gateway service to enable caching, Rate Limit policies (e.g. Quota, Spike Arrest, or Concurrent Rate Limit) and de

Processing

Check if all the endpoints are protected behind authentication to avoid broken authentication process.
User own resource ID should be avoided. Use /me/orders instead of /user/654321/orders.
Don't auto-increment IDs. Use UUID instead.
If you are parsing XML files, make sure entity parsing is not enabled to avoid XXE (XML external entity attack).
 If you are parsing XML files, make sure entity expansion is not enabled to avoid Billion Laughs/XML bomb via exponential en
Use a CDN for file uploads.
If you are dealing with huge amount of data, use Workers and Queues to process as much as possible in background and ret
Do not forget to turn the DEBUG mode OFF.

Output

Send X-Content-Type-Options: nosniff header.

Send X-Frame-Options: deny header.
Send Content-Security-Policy: default-src 'none' header.
Remove fingerprinting headers - X-Powered-By, Server, X-AspNet-Version, etc.
Force content-type for your response. If you return application/json, then your content-type response is application/json.
Don't return sensitive data like credentials, Passwords, or security tokens.
Return the proper status code according to the operation completed. (e.g. 200 OK, 400 Bad Request, 401 Unauthorized, 405

CI & CD

Audit your design and implementation with unit/integration tests coverage.

Use a code review process and disregard self-approval.
Ensure that all components of your services are statically scanned by AV software before pushing to production, including ve
Design a rollback solution for deployments.
Authenticated activities without authentication
/../../ in API endpoint : Directory traversal
IDOR: change object values in GET method,perform bruit force,SQL njection
Host header injection: Change the host and observe the Location field in response.
Add X-Forwarded-For: demo.testfire.net below the main host
Misconfigured CORS header : Add Origin header and check for Access-Control-Allow-Origin and Access-Control-Allow-
Crdentials header in response
Unrestricted resource consumption: Brute force attack on the requests and observe the response.
Security Misconfigurations: Check for all the headers
e.g.: Host,Origin(CORS),X-Content-Type,Content-Type,X-Frame-Option, (X-XSS-Protection)
Remove authorization token and hit all the APIS and observe the response.
Replace the auth tokens and observe the response.
Analyze,decode tokens,rebuild JWT tokens
Change ,remove, replace tokens and observe response/error message
Observe error messages for every API call.
Mass Assginment: Add appropriate values in parameter list, and those should be replicated in response.e.g. "admin" :
"true"
Response: Check for the security headers.X-Content-Type=nosniff,X-Frame-Option=deny,samorigine,content-security-
policy
Check for Excessive data exposures for every API call
Imrpoper Inventory Management: Check if any versions are appearing in the Endpoint
SQL, XSS and other injections on API qury parameters

CRLF Injection: Add %0d%0aTest in the request and if application is vulnerable to CRLF, Test word is reflected in the
response
e.g.: GET /Vapi/api5/getuser.php%0d%0aTest HTTP/1.1
Testing for Directory Listing: Modify endpoint by removing all the sub folder names and observe the response.
Checking for content type XML/JSON supports?: Convert body parameter to XML/JSON and observe is you are getting
response accordingly
Testing for dangerous methods: Change method type from GET to PUT/DELETE and observe if respective action is taking
place.
Change method tyeps and observe the response:if any request works for both GET and POST methods.
 Vulnearbility Title

API1:2019 Broken Object Level Authorization

API2:2019 Broken User Authentication

API3:2019 Excessive Data Exposure

API4:2019 Lack of Resources & Rate Limiting

API5:2019 Broken Function Level Authorization

API6:2019 Mass Assignment

API7:2019 Security Misconfiguration

API8:2019 Injection

API9:2019 Improper Assets Management

API10:2019 Insufficient Logging & Monitoring

 How to Exploite?

e.g.: GET api/users/2345/orders

In this HTTP request ,modify user ID and see if you can see other
user's order details.

e.g.Brute force on OTP request.

Observe response for every API call,and check if USer ID,any token
or any extra information is being passed.

Brute force on API call

e.g.: Change GET by DELETE method.

Mass Assignment in which a malicious user modifies properties that

they are not supposed to on the data objects stored in the backend,
gaining unauthorized access or corrupting data as a result.
e.g.: Is admin extra field was there in request which modified to
TRUE

e.g.: clickjacking,Misconfigured CORS

e.g.: ' , sqlmap ,sleep command
If application accepts XML file then XXE is possible.
<!DOCTYPE loadthis [<!ELEMENT loadthis ANY >
<!ENTITY somefile SYSTEM "file:///etc/passwd" >]>
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="CDA.xsl"?>

Deprecated endpoint.e.g: older version endpoint can be misused

Insufficient logged details

 Mitigations

Don't trust ID coming from Get request.Take user ID from session.If

no ID is in session that means user is not authenticated to perform
the activity.
Check the assigned access controls for users.
Assign appropriate access controls to all the users and groups.
Increase the token length from 4 characters to a minimum of 8,
Add progressive delays or rate-limit the attempts to submit a new
token. 5 max try login attempts.
Add CAPTCHA to log in, registration, and two-factor authentication
forms.

Never rely on the client-side to filter sensitive data.

Each API endpoint only responds with the data which is essential
Developers shouldpurpose
for the endpoint's implement
andadoes
limit not
on how
leak often a client
any other can call
data.
the API within a defined timeframe.
Additionally, a generic response message should be displayed as a
response instead of an field-specific one, regardless of whether or
not the username, email or account is valid.

To effectively mitigate against Broken function-level authorization

vulnerabilities, developers must enforce proper authentication and
authorization checks for each API endpoint, even if some of them
are "hidden" from the user interface perspective.

All the parameters and payloads the method is expecting are

explicitly defined instead of relying on the generic entity objects
passed as parameters.
Additionally, all schemas and types that are expected in the
requests should be explicitly defined at design time and enforced at
runtime.
To mitigate against Clickjacking attacks, developers must configure
their web servers or load balancers to include X-Frame-Options or
Content-Security-Policy header.
Both X-Frame-Options andContent-Security-Policy response
headers define whether or not a browser should be allowed to
embed or render a page in an <iframe> element. For example,
setting X-Frame-Options: deny will prevent browsers from
rendering your web application in an <iframe> element.
SQL Injection attacks, developers must use prepared statements
(also known as parameterized queries) when building SQL queries
based on user input.
In order to effectively mitigate against XXE injection attacks,
developers must configure their application's XML parsers to
disable the parsing of XML eXternal Entities (XXE) and Document
Type Definitions (DTD) when parsing XML documents.
If DTDs cannot be completely disabled, developers must disable
the parsing of external general entities and external parameter
entities when parsing untrusted XML files.

Always make sure that no outdated or legacy API endpoints are

Ensure
availableallfor
login,
use access control failures,
in the production and server-side input
environment.
validation failures can be logged with sufficient user context to
identify suspicious or malicious accounts, and held for sufficient
time to allow delayed forensic analysis.
Ensure that logs are generated in a format that can be easily
consumed by centralized log management solutions.
Ensure sensitive actions have an audit trail with integrity controls to
prevent tampering or deletion, such as append-only database
tables or similar.
Establish effective monitoring and alerting such that suspicious
activities are detected and responded to in a timely fashion.
URLs
https://github.com/shieldfy/API-Security-Checklist
https://auth0.com/docs/authorization/flows/authorization-code-flow
https://infosecwriteups.com/oauth-2-0-hacking-simplified-part-2-vulnerabilities-and-mitigation-d01dd6d5fa2c
https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
https://application.security/free/owasp-top-10-API
Tools:
Postman + Burp Suite Free
d01dd6d5fa2c
 Scenario Name
Recon/Information Gathering:
Generate Error Messages
Do not pass technical details (e.g. call stacks or other internal hints)to the client
Send different types of data that it's not expecting(String/int/bool/array etc.)
Try all methods(GET/POST/PATCH/PUT/DELETE,QWE)
Send malformed JSON {"Username":"admin""}
Authentication
Don't use Basic Auth. Use standard authentication instead (e.g. JWT, OAuth).
Don't reinvent the wheel in Authentication, token generation, password storage. Use the
standards.
Use Max Retry and jail features in Login.
Use encryption on all sensitive data.
Acess Contrl Bugs:
Enumerating potentially restricted endpoints
Modifying session tokens
Reusing older session tokens
Attempt to bypass restrictions on access with IDOR
Modifying the request with additional prameters like"&admin=True' or others
Modifying referrer headers that the application may expect.
Input Validation
Parameters within the URL
Parameters within the request
File uploads(PUT/DELETE requests)
Different request methods
Remote code Execution : "groovyscript":"def cmd"\sleep10\",XXE,XSS
Cross site scripting
Local/Remote file inclusion
SQL/NOSQL injection: '
Request Splitting
Deseralization
XXE and other templated language fun
Encoding errors with Junk characters,control characters,Emoji etc
File Upload Vulnerabilities
SSRF
JWT (JSON Web Token)
Use
Don't extract the algorithm from the Secret)
a random complicated key (JWT header.toForce
makethebrute forcinginthe
algorithm thetoken very(HS256
backend hard.
or RS256).
Make token expiration (TTL, RTTL) as short as possible.
Don't store sensitive data in the JWT payload, it can be decoded easily.
Ensure JWTs are integrity protected by either a signature or a MAC.
Do not allow the unsecured JWTs: {"alg":"none"}.
In general, signatures should be preferred over MACs for integrity protection of JWTs.
OAuth
Always validate redirect_uri server-side to allow only whitelisted URLs.
Always try to exchange for code and not tokens (don't allow response_type=token).
Use state parameter with a random hash to prevent CSRF on the OAuth authentication
process.
Define the default scope, and validate scope parameters for each application.
Access
Limit requests (Throttling) to avoid DDoS / brute-force attacks.
Use HTTPS on server side to avoid MITM (Man in the Middle Attack).
Use HSTS header with SSL to avoid SSL Strip attack.
Use the proper
For private APIs,HTTP
only method according
allow access to the operation:
from whitelisted GET (read), POST (create),
IPs/hosts.
PUT/PATCH (replace/update), and DELETE (to delete a record), and respond with 405
Method Not Allowed if the requestedInput Validation
method isn't appropriate for the requested
resource.

Validate content-type on request Accept header (Content Negotiation) to allow only your
supported format (e.g. application/xml, application/json, etc.) and respond with 406 Not
Acceptable response if not matched.
Validate content-type of posted data as you accept (e.g. application/x-www-form-
urlencoded, multipart/form-data, application/json, etc.).
Validate user input to avoid common vulnerabilities (e.g. XSS, SQL-Injection, Remote Code
Execution, etc.).
Don't use any sensitive data (credentials, Passwords, security tokens, or API keys) in the
URL, but use standard Authorization header.
Use an API Gateway service to enable caching, Rate Limit policies (e.g. Quota, Spike
Arrest, or Concurrent Rate Limit) and deploy APIs resources dynamically.
Content Type Vaidation
Reject requests containing unexpected or missing content typeheaders with HTTP
response status 406 Unacceptable or 415Unsupported Media Type.
Reject the request ( Ideally with a 406 Not Acceptable response) if theAccept header does
not specifically contain one of the allowable types.

Ensure sending intended content type headers in your response matching your body
content e.g. application/json and notapplication/javascript.
For XML content types ensure appropriate XML parser hardening, see the
XXE cheat sheet
Processing
Check if all the endpoints are protected behind authentication to avoid broken
authentication process.

User own resource ID should be avoided. Use /me/orders instead of /user/654321/orders.

Don't auto-increment IDs. Use UUID instead.(Universally Unique Identifiers: Big random
numbers)
If you are parsing XML files, make sure entity parsing is not enabled to avoid XXE (XML
external entity attack).
If you are parsing XML files, make sure entity expansion is not enabled to avoid Billion
Laughs/XML bomb via exponential entity expansion attack.
Use a CDN for file uploads.Content Delivery Network (CDN)

If you are dealing with huge amount of data, use Workers and Queues to process as much
as possible in background and return response fast to avoid HTTP Blocking.
Do not forget to turn the DEBUG mode OFF.
Management Endpoint
Avoid exposing management endpoints via Internet.
If management endpoints must be accessible via the Internet, makesure that users must
use a strong authentication mechanism, e.g.multi-factor.
Expose management endpoints via different HTTP ports or hosts preferably on a different
NIC and restricted subnet.
Restrict access to these endpoints by firewall rules or use of access control lists.
API Keys
Enforce API keys for every request to the protected endpoint.

Return 429 Too Many Requests HTTP response code if requests are coming in too quickly.
Revoke the API key if the client violates the usage agreement.

Do not rely exclusively on API keys to protect sensitive, critical or high-value resources.
API Output Checks
Send X-Content-Type-Options: nosniff header.
Send X-Frame-Options: deny header.
Send Content-Security-Policy: default-src 'none' header.
Remove fingerprinting headers - X-Powered-By, Server, X-AspNet-Version, etc.
Force content-type for your response. If you return application/json,then your content-
type response is application/json.
Don't return sensitive data like credentials, Passwords, or security tokens.

Return the proper status code according to the operationcompleted. (e.g. 200 OK, 400
Bad Request, 401 Unauthorized, 405Method Not Allowed, etc.).
No Rate limitting
3rd Party API Abuse
Request Splitting: Making additional requests to 3rd party API through the target API

SSRF: APIS that can resolve URLs can be tricked in to making requests in the cotext of the
other server.
Unhandeled input from 3rd party
It can result in to unexpected errors in to target application
Audit Logs
Write audit logs before and after security related events.
Consider logging token validation errors in order to detect attacks.
Take care of log injection attacks by sanitising log data beforehand
CI & CD
Audit your design and implementation with unit/integration tests coverage.
Use a code
Ensure thatreview process and
all components disregard
of your self-approval.
services are statically scanned by AV software before
pushing to production, including vendor libraries and other dependencies.
Design a rollback solution for deployments.