Secure Coding & OWASP Top 10 for Backend · レッスン

APIのレート制限とスロットリング

レート制限がAPIを悪用、ブルートフォース攻撃、サービス拒否攻撃から守る仕組みと、トークンバケットやスライディングウィンドウ方式を実装する方法を学びます。

「APIのレート制限とスロットリング」はCoddyKit上の無料Secure Coding & OWASP Top 10 for Backendレッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはSecure Coding & OWASP Top 10 for Backend学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Secure Coding & OWASP Top 10 for Backendコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Why Rate Limiting?

Rate limiting caps how many requests a client can make in a time window. It protects APIs from brute-force attacks, scraping, accidental loops, and denial-of-service.

It is a key control listed under API security best practices.

Throttling vs Limiting

Rate limiting rejects requests over a hard cap; throttling slows them down (queuing or delaying) instead of rejecting outright. Both manage load and abuse, often used together.

What to Limit On

Choose a key to count requests against:

API key or user ID for authenticated traffic
IP address for anonymous traffic
Endpoint sensitivity (stricter limits on login)

Combining keys gives finer control and resists simple bypasses.

Fixed Window

The simplest approach counts requests in a fixed time window, resetting the counter each period. It is easy but allows bursts at window edges (twice the limit across a boundary).

import time

window = {}
LIMIT = 5
PERIOD = 60

def allow(key):
    now = int(time.time() // PERIOD)
    count = window.get((key, now), 0)
    if count >= LIMIT:
        return False
    window[(key, now)] = count + 1
    return True

Token Bucket

The token bucket refills tokens at a steady rate up to a capacity. Each request consumes a token; an empty bucket means the request is rejected. It allows controlled bursts while enforcing an average rate.

import time

class TokenBucket:
    def __init__(self, rate, capacity):
        self.rate = rate
        self.capacity = capacity
        self.tokens = capacity
        self.last = time.time()
    def allow(self):
        now = time.time()
        self.tokens = min(self.capacity, self.tokens + (now - self.last) * self.rate)
        self.last = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

Sliding Window

The sliding window tracks timestamps of recent requests and counts only those within the last N seconds. It avoids the burst problem of fixed windows at the cost of more bookkeeping.

Distributed Rate Limiting

With multiple servers, counters must be shared. A central store like Redis holds the counters so limits apply across the whole cluster, not per instance. Use atomic operations to avoid race conditions.

Communicating Limits

Tell clients about their limits with response headers so well-behaved clients can back off.

headers = {
    'X-RateLimit-Limit': '100',
    'X-RateLimit-Remaining': '42',
    'X-RateLimit-Reset': '1717000000',
    'Retry-After': '30',
}
for k, v in headers.items():
    print(k + ': ' + v)

Status Codes

Return 429 Too Many Requests when a client exceeds the limit, ideally with a Retry-After header. This is the standard signal clients and SDKs expect.

Protecting Sensitive Endpoints

Apply stricter limits to high-risk endpoints like login, password reset, and OTP verification. Tight limits here directly blunt brute-force and credential-stuffing attacks.

Login: a few attempts per minute
Password reset: a few per hour
General reads: generous limits

Avoiding Pitfalls

Watch for bypasses: rotating IPs, missing limits on some routes, and limits that reset on server restart. Place rate limiting at the gateway or middleware layer so every route is covered consistently.

Quick Check

Test your understanding of rate limiting.

Recap

You learned why APIs need rate limiting, how to choose a limiting key, and the trade-offs of fixed-window, token-bucket, and sliding-window strategies. You also saw distributed limiting with Redis, the 429 response, and stricter limits for sensitive endpoints.

よくある質問

「APIのレート制限とスロットリング」レッスンは無料ですか？

はい。「APIのレート制限とスロットリング」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Secure Coding & OWASP Top 10 for Backendコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Secure Coding & OWASP Top 10 for Backendコースには全4レッスンが含まれています。

「APIのレート制限とスロットリング」で何を学びますか？

レート制限がAPIを悪用、ブルートフォース攻撃、サービス拒否攻撃から守る仕組みと、トークンバケットやスライディングウィンドウ方式を実装する方法を学びます。ブラウザで直接実行するハンズオンコードでSecure Coding & OWASP Top 10 for Backendを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Secure Coding & OWASP Top 10 for Backendを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのSecure Coding & OWASP Top 10 for Backendは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン4/4です。

「APIのレート制限とスロットリング」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このSecure Coding & OWASP Top 10 for Backendレッスンでコードを書いて実行できますか？

はい。すべてのSecure Coding & OWASP Top 10 for Backendレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Secure Coding & OWASP Top 10 for Backendに戻る