Skip to content

xaferima/API-Pentesting-Checklist

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
 
 
 
 

Repository files navigation

Español

API Security Checklist

Checklist of the most important security countermeasures when designing, testing, and releasing your API.


Enumeration

  • Use a fuzzer for discover new APIs. For several levels.
  • Enumerate restricted endpoints. For trying to bypass. Add to the final endpoint(..;/, etc).
  • Modifying the request for additional parameters. For example: &admin=true.

Authentication

  • Don't use Basic Auth. Use standard authentication instead (e.g., JWT).
  • 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.
  • Reusing old session tokens

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.
  • Avoid storing too much data. JWT is usually shared in headers and they have a size limit.
  • More attacks about JWT: https://www.invicti.com/blog/web-security/json-web-token-jwt-attacks-vulnerabilities/

Access

  • Limit requests (Throttling) to avoid DDoS / brute-force attacks.
  • Use HTTPS on server side with TLS 1.2+ and secure ciphers to avoid MITM (Man in the Middle Attack).
  • Use HSTS header with SSL to avoid SSL Strip attacks.
  • Turn off directory listings.
  • For private APIs, allow access only from safelisted IPs/hosts.

Authorization

OAuth

  • Always validate redirect_uri server-side to allow only safelisted 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 authorization process.
  • Define the default scope, and validate scope parameters for each application.

Input

  • Lack of input sanitization / Escaping unsafe characters.
  • Use the proper HTTP method according to the operation: GET (read), POST (create), PUT/PATCH (replace/update), and DELETE (to delete a record), and respond with 405 Method Not 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/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.
  • Modifying referrer headers that the API may expect.
  • Use only server-side encryption.
  • 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.
  • Test file uploads request.
  • Cross-site Request Forgery (CSRF) — If your API accepts the same authentication configuration that your interactive users use, then you might be vulnerable to a CSRF attack. For example, if your interactive users login and get a “SESSIONID” cookie, and that cookie can also be used to invoke API requests, then a carefully composed HTML form could make unexpected API requests on behalf of your users.
  • IDOR in body/header is more vulnerable than ID in URL. For example: {“id”:{“id”:111}}

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 data, make sure entity parsing is not enabled to avoid XXE (XML external entity attack).
  • If you are parsing XML, YAML or any other language with anchors and refs, make sure entity expansion is not enabled to avoid Billion Laughs/XML bomb via exponential entity expansion attack.
  • 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 return response fast to avoid HTTP Blocking.
  • Do not forget to turn the DEBUG mode OFF.
  • Use non-executable stacks when available.
  • If found GET /api/v1/users/ try DELETE / POST to create/delete users

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 Method Not Allowed, etc.).
  • DoS Limit: /api/news?limit=100 -> /api/news?limit=9999999999

Monitoring

  • Use centralized logins for all services and components.
  • Use agents to monitor all traffic, errors, requests, and responses.
  • Use alerts for SMS, Slack, Email, Telegram, Kibana, Cloudwatch, etc.
  • Ensure that you aren't logging any sensitive data like credit cards, passwords, PINs, etc.
  • Use an IDS and/or IPS system to monitor your API requests and instances.

Wordlists

See also:


About

API-Pentesting-Checklist

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published