Awesome
繁中版 | 简中版 | العربية | Azərbaycan | বাংলা | Català | Čeština | Deutsch | Ελληνικά | Español | فارسی | Français | हिंदी | Indonesia | Italiano | 日本語 | 한국어 | ພາສາລາວ | Македонски | മലയാളം | Монгол | Nederlands | Polski | Português (Brasil) | Русский | ไทย | Türkçe | Українська | Tiếng Việt | Български
API Security Checklist
Checklist of the most important security countermeasures when designing, testing, and releasing your API.
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.
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
orRS256
). - 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.
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
- Use the proper HTTP method according to the operation:
GET (read)
,POST (create)
,PUT/PATCH (replace/update)
, andDELETE (to delete a record)
, and respond with405 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 with406 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
, orAPI keys
) in the URL, but use standard Authorization header. - Use only server-side encryption.
- Use an API Gateway service to enable caching, Rate Limit policies (e.g.,
Quota
,Spike Arrest
, orConcurrent Rate Limit
) and deploy APIs resources dynamically.
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.
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 returnapplication/json
, then yourcontent-type
response isapplication/json
. - Don't return sensitive data like
credentials
,passwords
, orsecurity 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.).
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 vendor libraries and other dependencies.
- Continuously run security tests (static/dynamic analysis) on your code.
- Check your dependencies (both software and OS) for known vulnerabilities.
- Design a rollback solution for deployments.
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.
See also:
- yosriady/api-development-tools - A collection of useful resources for building RESTful HTTP+JSON APIs.
Contribution
Feel free to contribute by forking this repository, making some changes, and submitting pull requests. For any questions drop us an email at team@shieldfy.io
.