API Rate Limiting and Abuse Prevention Test Prompt

This prompt is designed for reliability and security testers who need to systematically validate that an API's rate-limiting and abuse-prevention controls behave correctly under load. The primary job-to-be-done is generating a concrete, reproducible test plan that probes rate-limit thresholds, common bypass techniques (such as header spoofing and IP rotation), and the API's degradation behavior when limits are exceeded. The ideal user is an SDET, AppSec engineer, or platform reliability engineer who already has access to the API's documented rate-limit policy, authentication mechanisms, and a non-production environment safe for burst testing.

Use this prompt when you have a specific API endpoint or set of endpoints to test and a defined rate-limit policy (e.g., '100 requests per minute per API key'). It is most effective when you can provide the exact HTTP method, URL, required headers, and authentication scheme as input context. The prompt produces a burst-profile plan, expected 429 (Too Many Requests) response validation checks, and Retry-After header inspection steps. It also generates test cases for common bypass attempts, including X-Forwarded-For header spoofing, alternating API keys, and parameter mutation to evade rate-limit counters.

Do not use this prompt against production endpoints or live user accounts. The generated test plan is intentionally aggressive and will trigger rate-limiting, potentially causing denial of service for legitimate traffic if executed in the wrong environment. This prompt is also not a substitute for a full load-testing tool; it produces a test design, not an execution script. If you need to generate the actual k6, Locust, or JMeter script, pair this prompt with a code-generation step. For high-risk financial or healthcare APIs, always add a human review gate before executing any generated test plan, and ensure the test environment is fully isolated from production data and systems.

After using this prompt, take the generated test plan and adapt the burst profiles to your specific rate-limit tiers. Validate that every test case includes a clear expected response (status code, body structure, headers) and a pass/fail criterion. The next step is to wire the plan into your test harness with logging, retry suppression, and a safety check that confirms the target host is a non-production environment before sending any traffic.

This prompt template is designed to produce a structured, executable test plan for API rate limiting and abuse prevention controls. It accepts the target API specification, known rate-limit policies, and any specific bypass techniques you want to probe. The output is a burst-profile plan, expected 429 Too Many Requests response validation checks, and Retry-After header assertions. Use this template when you have a clear rate-limit policy document or API gateway configuration to test against. Do not use it for general performance or load testing; it is focused on threshold enforcement and abuse-detection logic.

textCopy
You are a reliability and security test engineer designing test scenarios for API rate limiting and abuse prevention controls.

Your task is to produce a detailed, reproducible test plan based on the provided API specification and rate-limit policy.

## INPUTS
[API_SPECIFICATION]
[RATE_LIMIT_POLICY]
[BYPASS_TECHNIQUES_TO_TEST]

## CONSTRAINTS
- Generate only non-destructive test scenarios. Do not include tests that would cause data loss, denial of service to other users, or violate the target environment's acceptable use policy.
- For each test case, specify the exact request parameters, headers, and timing.
- All test cases must be safe to execute in a staging or pre-production environment that mirrors production rate-limit configuration.
- If the [RATE_LIMIT_POLICY] is incomplete or ambiguous, flag the missing information and state the assumptions you are making.

## OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "test_plan_name": "string",
  "assumptions": ["string"],
  "test_scenarios": [
    {
      "scenario_id": "string",
      "scenario_name": "string",
      "abuse_vector": "threshold_breach | header_spoofing | ip_rotation | other",
      "description": "string",
      "preconditions": ["string"],
      "request_profile": {
        "target_endpoint": "string",
        "http_method": "string",
        "headers": {},
        "body_template": "string or null",
        "concurrent_connections": "integer",
        "request_interval_ms": "integer",
        "burst_size": "integer",
        "total_requests": "integer"
      },
      "expected_response": {
        "status_code": "integer",
        "body_contains": ["string"],
        "headers": {
          "Retry-After": "string or null",
          "X-RateLimit-Remaining": "string or null"
        }
      },
      "validation_checks": ["string"],
      "cleanup_steps": ["string"]
    }
  ],
  "coverage_summary": {
    "threshold_tests": "integer",
    "bypass_tests": "integer",
    "degradation_tests": "integer"
  }
}

## INSTRUCTIONS
1. Parse the [RATE_LIMIT_POLICY] to identify explicit thresholds (requests per second, per minute, per IP, per token).
2. For each threshold, design a burst scenario that exceeds it and a sustained scenario that approaches it without exceeding it.
3. For each bypass technique listed in [BYPASS_TECHNIQUES_TO_TEST], design a specific test case that attempts the bypass and defines the expected security control response.
4. Include at least one test case that validates graceful degradation behavior (e.g., the API returns 429 instead of crashing).
5. For every test case that expects a 429 response, include a validation check for the `Retry-After` header format and value.
6. If the [API_SPECIFICATION] includes authentication requirements, generate test cases for both authenticated and unauthenticated rate-limit scopes.

To adapt this template, replace the square-bracket placeholders with your concrete inputs. The [API_SPECIFICATION] should be a structured OpenAPI snippet or a clear textual description of the endpoints under test. The [RATE_LIMIT_POLICY] should include explicit thresholds, the counting window, and the scope (e.g., per IP, per API key). The [BYPASS_TECHNIQUES_TO_TEST] is a list of specific evasion methods you want to probe, such as X-Forwarded-For header spoofing, IP rotation across a pool, or varying request paths to bypass per-endpoint limits. After generating the test plan, always review the assumptions field to ensure the model did not fill gaps in your policy with unsafe guesses. For high-risk production environments, require a human to approve the test plan before execution and run tests only in a dedicated staging environment that mirrors production rate-limit configuration.

This prompt is designed to be called programmatically within a security testing harness, not as a one-off chat interaction. The harness should supply the target API's rate-limit policy document, authentication method, and a list of endpoint signatures as structured inputs. The model's output—a burst-profile plan with specific request sequences, expected 429 responses, and Retry-After header assertions—must be parsed as structured JSON and fed into a test executor (e.g., a custom script, k6, or a Postman collection runner). Because the prompt generates attack scenarios that will actually send traffic to a target, the harness must enforce a pre-flight safety check: confirm the target environment is a designated test/staging endpoint, not production, and that any authentication tokens used are test-only credentials with no access to live data.

After the model returns the test plan, the harness should validate the output against a strict schema before execution. Required fields per test case include: test_id, endpoint, http_method, burst_profile (requests per second, ramp-up period, total requests), expected_status, expected_retry_after_header_present (boolean), and bypass_attempt (e.g., header spoofing, IP rotation via X-Forwarded-For). If any test case is missing these fields or contains values outside acceptable ranges (e.g., burst rates that would overwhelm the test infrastructure itself), the harness should reject the plan and either retry the prompt with a more constrained [CONSTRAINTS] block or escalate for human review. Log every generated plan and its validation result for auditability—rate-limit testing can resemble a denial-of-service attack, and you need a clear record that the traffic was authorized and scoped.

For execution, the harness should implement a circuit breaker: if the target API returns 5xx errors instead of the expected 429s, or if latency spikes beyond a threshold, halt the test immediately and flag the result for manual investigation. After execution, compare actual responses against the expected outcomes from the prompt. A post-execution evaluation step should calculate coverage metrics: what percentage of the rate-limit policy's stated thresholds were tested, how many bypass techniques were attempted, and whether any Retry-After headers contained values inconsistent with the documented policy. Feed these results back into your regression test suite so that rate-limit behavior is re-verified on every release. Avoid running this prompt's output unattended against third-party APIs without explicit written authorization—rate-limit probing can violate terms of service and trigger automated abuse blocks.