KO | EN

GitLite

Minimalist Open Source Repository Search Engine

gitlite — search

#developer-tools #codex #typescript #ai-agents #claude-code #dsh #dsh-plugin #deepseek-harness #cli #macos #ai-agent #open-source

API-Pentesting-Checklist

★ 28 Open GitHub ↗

API-Pentesting-Checklist

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

[Español](./README-es.md)

# 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](https://jwt.io/)).
- [ ] 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](https://jwt.io/#debugger-io).
- [ ] 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/<id> 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
- https://github.com/chrislockard/api_wordlist
- https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/common-api-endpoints-mazen160.txt
- https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content/api
- https://github.com/fuzzdb-project/fuzzdb/blob/master/discovery/common-methods/common-methods.txt
  
## See also:
- Web API Pentesting (https://book.hacktricks.xyz/network-services-pentesting/pentesting-web/web-api-pentesting)
- Resources and tools (https://www.apisec.ai/blog/api-security-checklist)
- Common end points (https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/common-api-endpoints-mazen160.txt)
- A collection of useful resources for building RESTful HTTP+JSON APIs (https://github.com/yosriady/api-development-tools) 
- Full check list (https://github.com/shieldfy/API-Security-Checklist)

---

API-Pentesting-Checklist

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README