Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/shieldfy/API-Security-Checklist below:

shieldfy/API-Security-Checklist: Checklist of the most important security countermeasures when designing, testing, and releasing your API

繁中版 | 简中版 | العربية | Azərbaycan | Български | বাংলা | Català | Čeština | Deutsch | Ελληνικά | Español | فارسی | Français | हिंदी | Indonesia | Italiano | 日本語 | 한국어 | ພາສາລາວ | Македонски | മലയാളം | Монгол | Nederlands | Polski | Português (Brasil) | Русский | ไทย | Türkçe | Українська | Tiếng Việt

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

• 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.

• 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.

• 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) and ensure Host header matches the SNI.
• Use HSTS header with SSL to avoid SSL Strip attacks.
• Turn off directory listings.
• For private APIs, allow access only from safelisted IPs/hosts.

• 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.

• 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.
• 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.

• 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.

• 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.).

• 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.

• 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.

• yosriady/api-development-tools - A collection of useful resources for building RESTful HTTP+JSON APIs.

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.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4