"GitHub engineers recently traced user reports of unexpected "Too Many Requests" errors to abuse-mitigation rules that had accidentally remained active long after the incidents that prompted them. According to GitHub, the affected users were not generating high-volume traffic; they were "making a handful of normal requests" that still tripped protections. The investigation found that older incident rules were based on traffic patterns that were strongly associated with abuse at the time, but later began matching some legitimate, logged-out requests."
"Specifically those that also triggered business-logic rules resulting in roughly 0.5 - 0.9% of fingerprint matches being blocked, while false positives were a tiny fraction of total traffic (on the order of a few requests per 100,000). Even so, the post argues that the user impact was unacceptable, and uses the episode to highlight a broader operational pattern: emergency controls are often correct during an active incident, but "don't age well as threat patterns evolve and legitimate tools and usage change"."
Engineers traced "Too Many Requests" errors to abuse-mitigation rules that remained active long after the incidents that prompted them. Affected users were not generating high-volume traffic; they were making a handful of normal requests that still tripped protections. Older incident rules relied on traffic patterns tied to past abuse but later matched some legitimate, logged-out requests. Detections combined industry-standard fingerprinting with platform-specific business logic, producing occasional false positives. Only 0.5–0.9% of fingerprint matches were blocked, with false positives on the order of a few requests per 100,000. Layered defenses complicated attribution because multiple systems can rate-limit or block.
Read at InfoQ
Unable to calculate read time
Collection
[
|
...
]