セキュアな API ゲートウェイを構築する方法
認証、レート制限、リクエストバリデーション、脅威対策を担う、セキュアな API ゲートウェイを設計します。
问题
バックエンドサービスがクライアントに直接公開されており、悪用、不正アクセス、不正な形式のリクエストに対して脆弱になっています。リクエストがサービスに到達する前にセキュリティポリシーを強制する単一の入口として、セキュアな API ゲートウェイが必要です。
前提条件
- HTTP API と REST/GraphQL パターンの理解
- 認証メカニズム（API キー、JWT、OAuth 2.0）への習熟
- OpenAPI/Swagger 仕様に関する知識
ステップ
-
1. Define the gateway security layers
Structure the gateway with layered security: (1) TLS termination with modern cipher suites, (2) request size and rate limits, (3) authentication (API key, JWT, OAuth), (4) authorization (scope/role checks), (5) input validation against schema, (6) threat protection (SQL injection, XSS, path traversal), (7) response filtering. Each layer can reject the request before it reaches the backend.
入力incoming HTTP request输出layers: TLS -> rateLimit -> auth -> authz -> validate -> threats -> backend -
2. Implement authentication and authorization
Support multiple auth methods: API keys for simple service-to-service, JWT for user sessions, OAuth 2.0 for delegated access. Validate JWT signatures using the issuer's public key, check expiration and audience claims. For API keys, hash-compare against stored hashes (never store plaintext). Enforce scope-based authorization: each endpoint requires specific scopes. Use the JWT parser to inspect tokens and the API spec validator to check endpoints.
入力Authorization: Bearer eyJhbG...输出auth: valid | user: alice | scopes: [read:data, write:data] -
3. Configure rate limiting and request validation
Apply tiered rate limits: per-IP, per-user, per-API-key, and global. Use token bucket or sliding window algorithms. Reject requests exceeding limits with HTTP 429 and Retry-After header. Validate every request against the OpenAPI schema: check required fields, types, formats, and value ranges. Reject malformed requests with HTTP 400 before they reach the backend. Use the API spec validator to enforce schema compliance.
入力100 requests/second from one IP输出HTTP 429 Too Many Requests | Retry-After: 1 -
4. Add threat protection and observability
Filter requests for common attack patterns: SQL injection (malicious quotes, UNION), XSS (script tags, event handlers), path traversal (../), and command injection. Use allow-lists rather than deny-lists where possible. Log all requests with correlation IDs, auth results, response codes, and latency. Monitor for anomalies: spike in 4xx/5xx, unusual request patterns, auth failures. Sanitize all error messages to avoid leaking internal details.
入力query: ' OR 1=1 --输出blocked: SQL injection pattern | HTTP 400
期待される結果
すべてのバックエンドサービスに対して認証・認可・レートリミット・バリデーションを行い、悪用や攻撃から保護する、完全な観測性を備えたセキュアな API ゲートウェイ。
よくあるエラー
- Validating JWT signature but not expiration or audience
- Check all claims: signature, exp, nbf, iss, aud, and scope. A valid signature with expired token is still invalid.
- Using deny-lists for threat protection
- Deny-lists are incomplete and bypassable. Use allow-lists (strict input validation against schema) as the primary defense, with deny-lists as supplementary.
- Rate limiting only by IP
- IP limits are bypassable via rotation and fail behind shared NAT. Apply per-user and per-API-key limits in addition to per-IP.
トラブルシューティング指引
- If legitimate users are rate-limited, implement tiered limits (higher for authenticated, lower for anonymous) and allow burst tokens.
- For GraphQL gateways, add query complexity analysis and depth limiting to prevent resource exhaustion via nested queries.
- If the gateway becomes a bottleneck, ensure it is stateless (use external Redis for rate limit counters) and horizontally scalable.
セキュリティ上の制限
- The gateway is a high-value target — compromise of the gateway compromises all services behind it. Secure it with the same rigor as critical services.
- All token validation and policy enforcement happen at the gateway; backend services should still verify auth independently (defense in depth).
- Error messages must not leak internal architecture, stack traces, or SQL errors.