P3 — Missing Rate Limiting on Sensitive API Endpoint

Severity: Medium (P3) Vulnerability Type: Missing Rate Limiting / Unrestricted Request Attempts CWE: CWE-307 — Improper Restriction of Excessive Authentication Attempts CVSS v3.1: 6.5 (example; final score should be calculated according to the actual endpoint and impact)

Description

A missing rate-limiting control was identified on a sensitive API endpoint responsible for processing authentication-related or account-sensitive requests.

During testing, the endpoint was observed to accept a large number of consecutive requests from the same client without implementing effective throttling, temporary blocking, progressive delays, CAPTCHA challenges, or other anti-automation mechanisms.

An attacker who obtains the required request format could therefore automate repeated requests against the endpoint. Depending on the functionality exposed by the endpoint, this behavior may facilitate credential-guessing, account enumeration, abuse of verification mechanisms, or excessive consumption of backend resources.

The issue is classified as P3 / Medium because exploitation generally requires an attacker to repeatedly interact with the affected functionality, while the ultimate impact depends on the endpoint's purpose and the presence of additional security controls.

Affected Component

Endpoint: https://target.example/api/v1/auth/verify

HTTP Method: POST

Affected Functionality: Authentication / verification API

Steps to Reproduce

1. Authenticate to the application using a valid test account, if authentication is required.
2. Intercept a legitimate request to the affected endpoint using Burp Suite.
3. Send the request to Repeater or Intruder.
4. Preserve the original request structure and modify only the relevant test parameter.
5. Send multiple consecutive requests from the same source.
6. Monitor the HTTP responses and response timing.
7. Continue the controlled test until the application's configured request threshold should reasonably have been reached.
8. Observe that the server continues accepting requests without returning an appropriate throttling response such as 429 Too Many Requests, imposing a meaningful delay, temporarily blocking the source, or otherwise limiting the request rate.

Observed Result

The application continued processing repeated requests from the same client without enforcing an effective server-side rate limit.

No meaningful throttling mechanism was observed during testing.

Expected Result

The application should enforce server-side rate limiting for sensitive operations.

After a defined number of requests within a specified time period, the application should implement appropriate controls such as:

• 429 Too Many Requests
• Temporary source/account throttling
• Progressive request delays
• CAPTCHA or equivalent anti-automation controls
• Account-based and IP-based rate limits
• Appropriate monitoring and alerting

Rate limiting should be enforced server-side rather than relying solely on client-side controls.

Security Impact

An attacker could automate requests against the affected functionality at a significantly higher rate than intended.

Depending on the endpoint's business purpose, this could potentially enable:

• Automated authentication attempts
• Abuse of password-reset or verification workflows
• User/account enumeration
• Automated token or OTP guessing
• Excessive resource consumption
• Increased feasibility of other application-layer attacks

The practical impact should be evaluated together with the functionality exposed by the affected endpoint.

Proof of Concept

During validation, repeated requests were generated against the affected endpoint using the same source and request structure.

The application continued responding normally instead of enforcing an effective request threshold.

For reporting purposes, the evidence should include:

Request #1  → HTTP 200
Request #2  → HTTP 200
Request #3  → HTTP 200
...
Request #N  → HTTP 200

Request #1  → HTTP 200
Request #2  → HTTP 200
Request #3  → HTTP 200
...
Request #N  → HTTP 200

with the corresponding timestamps demonstrating that the requests were processed without meaningful throttling.

Remediation

Implement robust server-side rate limiting for all sensitive and abuse-prone endpoints.

The recommended implementation should combine multiple controls:

1. Apply per-IP and per-account rate limits.
2. Return HTTP 429 Too Many Requests when the configured threshold is exceeded.
3. Introduce progressive delays for repeated failures.
4. Apply stricter controls to authentication, password-reset, OTP, and verification functionality.
5. Consider CAPTCHA or equivalent bot-detection mechanisms where appropriate.
6. Ensure rate limiting cannot be bypassed simply by modifying client-side parameters.
7. Log and monitor abnormal request patterns.
8. Consider distributed rate limiting where the application operates across multiple backend instances.