This lesson is about a class of vulnerability whose impact is rarely a single dramatic exploit, but the slow accumulation of damage that adds up to outages, fraud, and abuse complaints. The defects are not in the application's source code, exactly; they are in what the source code does not check. The endpoint accepts the request. The request is well formed. The response is a successful one. Nothing looks wrong on a single request.
What is wrong is the rate: the endpoint accepts the same request a thousand times in a row, from the same caller, with no slowdown, no challenge, no lockout. A control that should have been present is absent, or is present in a layer the attacker controls.
The typical absent or broken controls are:
- A CAPTCHA that the server validates but never invalidates, so a single solved answer can be replayed forever.
- A rate limit that runs in the browser as a disabled-button timer, with no server-side equivalent.
- An account lockout policy that never engages, because failed attempts are not counted.
- A uniform response that varies, so an attacker can enumerate which addresses are registered.
In this lesson you will:
- Inspect a simulated
POST /api/Feedbacksbody and its CAPTCHA fields in CAPTCHA Replay. - Describe in writing how to bypass the CAPTCHA by replaying a single solved answer, mapping to NovaCart's CAPTCHA Bypass challenge.
- Use Burst Tester to compare unthrottled and rate-limited server behavior.
- Discuss server-side rate limiting, the choice of key (per-IP, per-account, combined), and the durable fix that applies to every sensitive endpoint.
Estimated time: twenty to thirty minutes.
Prerequisites: complete business-logic-flaws; it establishes why client-side controls are not enforcement, which is the same principle this lesson applies to CAPTCHA tokens and rate-limit timers.
When you are ready, send the Continue signal.