Rate limiting is applied to payment submission endpoints

Payment endpoints without rate limiting are the primary target of automated carding attacks: bots enumerate stolen card numbers by submitting hundreds of small charges per minute, using your checkout as a free card-validity oracle. Each probe costs you a Stripe fee ($0.05–$0.30 per declined charge), triggers fraud signals on your account, and can result in Stripe account suspension. CWE-770 (Allocation of Resources Without Limits or Throttling) captures this exact attack vector. OWASP A07 (Identification and Authentication Failures) covers the authentication-bypass aspect of unauthenticated brute-force. PCI-DSS 4.0 Req 6.4 requires that web-facing applications be protected against known attack patterns including automated attacks.

Apply a sliding-window rate limit to every payment submission endpoint. Five attempts per minute per IP is a reasonable ceiling for legitimate users.

// app/api/payment/route.ts
import { Ratelimit } from '@upstash/ratelimit'
import { Redis } from '@upstash/redis'
import { headers } from 'next/headers'

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, '60 s'),
})

export async function POST(req: Request) {
  const ip = (await headers()).get('x-forwarded-for') ?? 'anonymous'
  const { success } = await ratelimit.limit(`payment:${ip}`)
  if (!success) return new Response('Too many requests', { status: 429 })

  // ... payment processing
}

For authenticated routes, layer user-ID-based limiting on top of IP limiting to catch cases where multiple IPs share the same compromised account.