概要
Rate limiting is the cheap defense most apps skip until it bites. The motivation is understandable — adding a Redis dependency, designing the limiter taxonomy, deciding on response codes, and testing the edge cases is real engineering work for a problem that hasn't bitten yet. Until it has. Then the incident postmortem reads: '4,200 successful credential-stuffing attempts before we noticed.' Modern credential dumps run into the billions of email/password pairs; even a 0.01% reuse rate against your service is hundreds of compromised accounts before lunch. The attacker has automation, distributed proxy networks, and patience. The defense has to be in place before they arrive — there's no graceful degradation when you're already on fire.
運作方式
Rate-limit weaknesses appear when sensitive workflows allow repeated attempts without enough throttling or friction. Attackers can use that gap for guessing, abuse, scraping, or cost-amplification.
影响范围
Credential stuffing successes — every reuse-of-leaked-password account belongs to the attacker. Direct financial cost when endpoints trigger paid services (SMS via Twilio, email via Sendgrid, voice OTPs). Email-deliverability damage when password-reset spam triggers spam-trap entries. Resource exhaustion if the auth path is expensive (bcrypt with high cost factor, database lookups, external IdP calls). Reputation damage when 'hacked accounts at $service' shows up in support tickets.
// what fixvibe checks
What FixVibe checks
FixVibe checks this class with verified-domain active testing that is bounded, non-destructive, and evidence-driven. Public reports describe the affected surface and remediation. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
铁壁防御
Add per-IP and per-account rate limits to every auth endpoint. The classic shape: 5 attempts per IP per 15 minutes for login; 3 password-reset requests per email per hour; 10 signups per IP per day. Use a distributed limiter (Redis, Upstash, Vercel KV) so multi-region apps share state. Layer per-credential locks: after N failed login attempts on the same email from any IP, require an emailed unlock link or step-up MFA before further attempts succeed. Add CAPTCHA challenges adaptively — first attempt is friction-free, third attempt requires a check, tenth attempt is locked out for an hour. Exponential backoff (each subsequent failure waits longer) is more graceful than hard cutoffs and harder to game with rotating proxies. As a defense-in-depth layer, monitor for suspicious request patterns at the WAF / CDN — Cloudflare's bot mitigation, AWS WAF rate-based rules, and similar can catch credential-stuffing campaigns by traffic shape before they hit your origin. For SMS-based endpoints, set hard per-day budgets — your bill should never be a surprise.