Rate Limiting
Also known as: Throttling, Request throttling, Login throttling
Rate limiting controls how often a user, device, or app can make requests or repeat an action within a set time.
Rate limiting controls how often a user, device, or app can make requests or repeat an action within a set time. It helps curb excessive use and keep a service usable. A limit might apply to failed sign-in attempts, password reset requests, or calls to an API.
How rate limiting works
A service counts activity against a rule, such as five failed sign-ins per minute. Once the limit is reached, it may refuse further requests until enough time has passed. A web API may respond with HTTP 429, meaning "Too Many Requests." A Retry-After header can tell the caller how long to wait.
Rules can group requests by account, IP address, or another identifier, and the choice matters. Staff in one clinic may share an internet address, so a strict limit per address could block the whole office. Symfony's login throttling handles this with two counters. A tight one covers each username and IP address pair, and a looser one covers the IP address alone. OWASP adds that failed sign-ins should count against the account, so an attacker cannot dodge the limit by switching addresses.
The counters also need a reliable store. CakePHP's docs warn that its File cache may not handle concurrent requests properly. Our CakePHP HIPAA compliant guide backs the limiter with Redis or Memcached instead.
A healthcare example
A patient portal might slow repeated failed sign-ins to reduce password guessing. This use is often called login throttling. NIST SP 800-63B says password checks must be rate limited, with no more than 100 failed attempts in a row on one account. Test both the limit and the recovery path, so a patient who mistypes a password can still get back in. OWASP warns that lockout rules can also be misused to deny access to other users.
Rate limiting in common PHP frameworks
Check that the sign-in page is covered. Yii 2's rate limiter skips visitors who are not logged in. Our Yii HIPAA compliant guide gives the login route its own limit, keyed by IP address or username.
An app that syncs appointment data may need a different limit from a sign-in page, so test each rule with real workloads. Our Laravel guide sets separate limits for login and PHI routes. Our Flight PHP guide adds a login limit that returns HTTP 429.
Rate limiting and HIPAA
The HIPAA Security Rule does not mention rate limiting. The closest provision is log-in monitoring, an addressable specification at 45 CFR § 164.308(a)(5)(ii)(C). It calls for "procedures for monitoring log-in attempts and reporting discrepancies." It sits under the security awareness and training standard. A login limiter can support it when blocked attempts are logged, reviewed, and reported.
Addressable does not mean optional. Under 45 CFR § 164.306(d)(3), you assess whether a specification is reasonable and appropriate. If it is, you implement it. If not, you document why and adopt an equivalent measure where reasonable and appropriate. Record that decision in your risk analysis. A proposed update to the Security Rule would drop the addressable label, but it is not final. Our new HIPAA Security Rule tracker follows its status.
What it does not replace
Authentication checks who is making a request. Access control decides what they may do. Rate limiting controls how often they may do it. A request below the limit still needs the right permissions. A rate limit does not stop cross-site request forgery (CSRF), because a forged request comes from the victim's own browser at normal volume. A limit also cannot stop someone who already has a valid password. Multi-factor authentication helps close that gap.
It is also only one layer of protection. An app-level limiter cannot absorb a large flood of traffic by itself. Symfony's documentation says its rate limiter is not useful against denial-of-service attacks, because the app must start before the limiter can run. Our Symfony HIPAA compliant guide puts that protection at the proxy or firewall instead. A web application firewall (WAF) or proxy in front of the app can drop excess requests before they reach it. See DDoS protection for the wider goal of keeping services reachable.
Sources: Symfony rate limiter documentation; Symfony login throttling; CakePHP rate limit middleware; Yii 2 RateLimiter API; MDN HTTP 429 reference; OWASP Authentication Cheat Sheet; NIST SP 800-63B; 45 CFR § 164.308 and § 164.306.