[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-10205":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":10,"languages":10,"totalLinesOfCode":10,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":15,"forks30d":15,"starsTrendScore":19,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":30,"readmeContent":31,"aiSummary":32,"trendingCount":15,"starSnapshotCount":15,"syncStatus":33,"lastSyncTime":34,"discoverSource":35},10205,"API-Security-Checklist","shieldfy\u002FAPI-Security-Checklist","shieldfy","Checklist of the most important security countermeasures when designing, testing, and releasing your API","",null,23261,2660,532,1,0,3,11,36,13,85.1,"MIT License",false,"master",true,[26,27,28,29],"api","jwt","oauth2","security","2026-06-12 04:00:49","[繁中版](.\u002FREADME-tw.md) | [简中版](.\u002FREADME-zh.md) | [العربية](.\u002FREADME-ar.md) | [Azərbaycan](.\u002FREADME-az.md) | [Български](.\u002FREADME-bg.md) | [বাংলা](.\u002FREADME-bn.md) | [Català](.\u002FREADME-ca.md) | [Čeština](.\u002FREADME-cs.md) | [Deutsch](.\u002FREADME-de.md) | [Ελληνικά](.\u002FREADME-el.md) | [Español](.\u002FREADME-es.md) | [فارسی](.\u002FREADME-fa.md) | [Français](.\u002FREADME-fr.md) | [हिंदी](.\u002FREADME-hi.md) | [Indonesia](.\u002FREADME-id.md) | [Italiano](.\u002FREADME-it.md) | [日本語](.\u002FREADME-ja.md) | [한국어](.\u002FREADME-ko.md) | [ພາສາລາວ](.\u002FREADME-lo.md) | [Македонски](.\u002FREADME-mk.md) | [മലയാളം](.\u002FREADME-ml.md) | [Монгол](.\u002FREADME-mn.md) | [Nederlands](.\u002FREADME-nl.md) | [Polski](.\u002FREADME-pl.md) | [Português (Brasil)](.\u002FREADME-pt_BR.md) | [Русский](.\u002FREADME-ru.md) | [ไทย](.\u002FREADME-th.md) | [Türkçe](.\u002FREADME-tr.md) | [Українська](.\u002FREADME-uk.md) | [Tiếng Việt](.\u002FREADME-vi.md)\n\n# API Security Checklist\n\nChecklist of the most important security countermeasures when designing, testing, and releasing your API.\n\n---\n\n## Authentication\n\n- [ ] Don't use `Basic Auth`. Use standard authentication instead.\n- [ ] Don't reinvent the wheel in `Authentication`, `token generation`, `password storage`. Use the standards.\n- [ ] Use `Max Retry` and jail features in Login.\n- [ ] Use encryption on all sensitive data.\n\n## Access\n\n- [ ] Limit requests (Throttling) to avoid DDoS \u002F brute-force attacks.\n- [ ] Use HTTPS on server side with TLS 1.2+ and secure ciphers to avoid MITM (Man in the Middle Attack) and ensure `Host` header matches the SNI.\n- [ ] Use `HSTS` header with SSL to avoid SSL Strip attacks.\n- [ ] Turn off directory listings.\n- [ ] For private APIs, allow access only from safelisted IPs\u002Fhosts.\n\n## Authorization\n\n### OAuth\n\n- [ ] Always validate `redirect_uri` server-side to allow only safelisted URLs.\n- [ ] Always try to exchange for code and not tokens (don't allow `response_type=token`).\n- [ ] Use `state` parameter with a random hash to prevent CSRF on the OAuth authorization process.\n- [ ] Define the default scope, and validate scope parameters for each application.\n\n## Input\n\n- [ ] Use the proper HTTP method according to the operation: `GET (read)`, `POST (create)`, `PUT\u002FPATCH (replace\u002Fupdate)`, and `DELETE (to delete a record)`, and respond with `405 Method Not Allowed` if the requested method isn't appropriate for the requested resource.\n- [ ] Validate `content-type` on request Accept header (Content Negotiation) to allow only your supported format (e.g., `application\u002Fxml`, `application\u002Fjson`, etc.) and respond with `406 Not Acceptable` response if not matched.\n- [ ] Validate `content-type` of posted data as you accept (e.g., `application\u002Fx-www-form-urlencoded`, `multipart\u002Fform-data`, `application\u002Fjson`, etc.).\n- [ ] Validate user input to avoid common vulnerabilities (e.g., `XSS`, `SQL-Injection`, `Remote Code Execution`, etc.).\n- [ ] Don't use any sensitive data (`credentials`, `Passwords`, `security tokens`, or `API keys`) in the URL, but use standard Authorization header.\n- [ ] Use only server-side encryption.\n- [ ] 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.\n\n## Processing\n\n- [ ] Check if all the endpoints are protected behind authentication to avoid broken authentication process.\n- [ ] User own resource ID should be avoided. Use `\u002Fme\u002Forders` instead of `\u002Fuser\u002F654321\u002Forders`.\n- [ ] Don't auto-increment IDs. Use `UUID` instead.\n- [ ] If you are parsing XML data, make sure entity parsing is not enabled to avoid `XXE` (XML external entity attack).\n- [ ] 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\u002FXML bomb` via exponential entity expansion attack.\n- [ ] Use a CDN for file uploads.\n- [ ] 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.\n- [ ] Do not forget to turn the DEBUG mode OFF.\n- [ ] Use non-executable stacks when available.\n\n## Output\n\n- [ ] Send `X-Content-Type-Options: nosniff` header.\n- [ ] Send `X-Frame-Options: deny` header.\n- [ ] Send `Content-Security-Policy: default-src 'none'` header.\n- [ ] Remove fingerprinting headers - `X-Powered-By`, `Server`, `X-AspNet-Version`, etc.\n- [ ] Force `content-type` for your response. If you return `application\u002Fjson`, then your `content-type` response is `application\u002Fjson`.\n- [ ] Do not return overly specific error messages to the client that could reveal implementation details, use generic messages instead, and log detailed information only on the server side.\n- [ ] Don't return sensitive data like `credentials`, `passwords`, or `security tokens`.\n- [ ] Return the proper status code according to the operation completed. (e.g., `200 OK`, `400 Bad Request`, `401 Unauthorized`, `405 Method Not Allowed`, etc.).\n\n## CI & CD\n\n- [ ] Audit your design and implementation with unit\u002Fintegration tests coverage.\n- [ ] Use a code review process and disregard self-approval.\n- [ ] Ensure that all components of your services are statically scanned by AV software before pushing to production, including vendor libraries and other dependencies.\n- [ ] Continuously run security tests (static\u002Fdynamic analysis) on your code.\n- [ ] Check your dependencies (both software and OS) for known vulnerabilities.\n- [ ] Design a rollback solution for deployments.\n\n## Monitoring\n\n- [ ] Use centralized logins for all services and components.\n- [ ] Use agents to monitor all traffic, errors, requests, and responses.\n- [ ] Use alerts for SMS, Slack, Email, Telegram, Kibana, Cloudwatch, etc.\n- [ ] Ensure that you aren't logging any sensitive data like credit cards, passwords, PINs, etc.\n- [ ] Use an IDS and\u002For IPS system to monitor your API requests and instances.\n\n---\n\n## See also:\n\n- [yosriady\u002Fapi-development-tools](https:\u002F\u002Fgithub.com\u002Fyosriady\u002Fapi-development-tools) - A collection of useful resources for building RESTful HTTP+JSON APIs.\n- You don't need JWT, just use a randomly generated API key. If you need asymmetric encryption or tamper prevention, [here are some alternatives to JWT](https:\u002F\u002Fkevin.burke.dev\u002Fkevin\u002Fthings-to-use-instead-of-jwt\u002F).\n\n---\n\n## API Security Best Practices (Advanced)\n\n### Rate Limiting & Abuse Prevention\n- [ ] Implement sliding window rate limiting per API key and IP.\n- [ ] Use exponential backoff for repeated failed authentication attempts.\n- [ ] Implement CAPTCHA or proof-of-work challenges after suspicious activity.\n- [ ] Monitor and alert on unusual API usage patterns (time, volume, endpoints).\n\n### GraphQL-Specific Security\n- [ ] Disable introspection in production environments.\n- [ ] Implement query depth limiting to prevent nested query attacks.\n- [ ] Use query cost analysis to prevent resource exhaustion.\n- [ ] Whitelist allowed queries in production when possible.\n\n### Secrets Management\n- [ ] Rotate API keys and secrets on a regular schedule.\n- [ ] Use hardware security modules (HSM) for signing operations.\n- [ ] Implement secret scanning in CI\u002FCD pipelines.\n- [ ] Never commit secrets to version control - use environment variables or secret managers.\n\n### Zero Trust Architecture\n- [ ] Implement mutual TLS (mTLS) for service-to-service communication.\n- [ ] Validate all requests even from internal services.\n- [ ] Use short-lived tokens with automatic refresh.\n- [ ] Implement request signing for sensitive operations.\n\n---\n\n# Contribution\n\nFeel 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`.\n","该项目提供了一份详尽的API安全检查清单，涵盖了从设计到发布整个过程中的关键安全措施。核心功能包括认证、访问控制、授权及输入验证等方面的最佳实践指导，特别强调了使用标准协议如OAuth2和JWT的重要性，并提供了防范常见攻击（如DDoS、SQL注入等）的具体建议。适用于所有需要构建或维护安全API接口的场景，无论是企业级应用还是个人开发者项目都能从中受益。",2,"2026-06-11 03:27:11","top_topic"]