IT Toolbox
Procedure

Protect an API with rate limiting

Protect an API with rate limiting without blocking legitimate clients by measuring baseline traffic, choosing the right key, testing limits in dry-run mode, defining burst behavior and HTTP 429 responses, and adding observability.

Applications & API

Objective

Protect an API with rate limiting without blocking legitimate clients by measuring baseline traffic, choosing the right key, testing limits in dry-run mode, defining burst behavior and HTTP 429 responses, and adding observability.

Prerequisites

  • Baseline request rates, client identity model and representative load tests.
  • Metrics for 2xx, 4xx, 5xx, latency and specifically HTTP 429 responses.
  • Administrative access appropriate to the system being changed or diagnosed.
  • A clearly identified scope: affected users, systems, addresses, services and the time of the observed problem.
  • A maintenance or test window when the procedure can affect production traffic or availability.
  • A copy of the current configuration or other recovery material before any irreversible action.

Step-by-step procedure

1

Establish the baseline and scope

Before changing anything, reproduce the issue or document the requested change on a representative system. Record the affected users or services, exact time, current configuration, recent changes and a known-good comparison point. This baseline is the reference used to decide whether each later step improves the situation.

Expected result
  • The scope and current state are documented well enough to reproduce or verify the procedure.
2

Rate limiting without blocking legitimate clients by measuring baseline traffic

Apply the required security control to this area: rate limiting without blocking legitimate clients by measuring baseline traffic. Start from the current effective configuration, apply least privilege and the smallest required exposure, then validate with representative privileged and non-privileged tests. Record every exception, its owner and its expiry so a temporary bypass cannot become permanent.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
3

The right key

Apply the required security control to this area: the right key. Start from the current effective configuration, apply least privilege and the smallest required exposure, then validate with representative privileged and non-privileged tests. Record every exception, its owner and its expiry so a temporary bypass cannot become permanent.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
4

Limits in dry-run mode

Apply the required security control to this area: limits in dry-run mode. Start from the current effective configuration, apply least privilege and the smallest required exposure, then validate with representative privileged and non-privileged tests. Record every exception, its owner and its expiry so a temporary bypass cannot become permanent.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
5

Burst behavior

Apply the required security control to this area: burst behavior. Start from the current effective configuration, apply least privilege and the smallest required exposure, then validate with representative privileged and non-privileged tests. Record every exception, its owner and its expiry so a temporary bypass cannot become permanent.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
6

HTTP 429 responses

Apply the required security control to this area: HTTP 429 responses. Start from the current effective configuration, apply least privilege and the smallest required exposure, then validate with representative privileged and non-privileged tests. Record every exception, its owner and its expiry so a temporary bypass cannot become permanent.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
7

Adding observability

Apply the required security control to this area: adding observability. Start from the current effective configuration, apply least privilege and the smallest required exposure, then validate with representative privileged and non-privileged tests. Record every exception, its owner and its expiry so a temporary bypass cannot become permanent.

Expected result
  • Evidence for this area is explicit, reproducible and consistent with the intended design.
8

Validate the complete service

Repeat the original user, system or application workflow from the real source and verify the complete result, not only one command or one local check. Confirm that logs and monitoring show the expected behavior and that no temporary debug, bypass, test account, rule or maintenance setting remains enabled.

Expected result
  • The end-to-end service works or the remaining failure is isolated to a clearly identified component.

Technical commands from the original procedure

These technical blocks are preserved byte-for-byte from the historical procedure and kept in their original order. Review names, addresses, paths and parameters before use.

Technical block 1
limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;
Technical block 2
nginx -t
Technical block 3
location /api/v1/ {
    limit_req zone=api_per_ip burst=20 nodelay;
    limit_req_dry_run on;
    limit_req_log_level notice;
    proxy_pass http://api_backend;
}
Technical block 4
nginx -t && nginx -s reload
Technical block 5
limit_req_status 429;
Technical block 6
nginx -t
Technical block 7
nginx -s reload
Technical block 8
for i in $(seq 1 40); do curl -s -o /dev/null -w '%{http_code}n' https://api.example.tld/api/v1/health; done

Validation

The procedure is validated when:

  • The original symptom or change request has been tested end to end.
  • The effective configuration matches the intended design and no unexplained error remains in the relevant logs.
  • Temporary troubleshooting controls have been removed and monitoring remains normal.
  • The result, evidence and any follow-up action are documented.

Rollback

  • Restore the configuration, policy, binding, route, credential assignment or service state recorded in the baseline when the change does not meet its success criteria.
  • Remove temporary rules, test objects and diagnostic settings that were introduced only for the procedure.
  • After rollback, repeat the minimum health checks to confirm that the previous service level has been restored.

Troubleshooting / common errors

  • Rate limits that look correct in a lab can overload one client class behind shared NAT or proxies.
  • Validate both rejection behavior and recovery after the configured window or token refill.
  • If the result changes between tests, compare source, destination, identity, time and policy context before changing additional settings.
  • If a command succeeds but the application still fails, continue at the next protocol or application layer instead of widening access.
  • If the expected evidence is missing, verify that logging, auditing and the test path actually cover the failing component.
  • If the change does not improve the measured symptom, restore the previous state and reassess the working hypothesis.

Official and vendor references preserved from the original procedure

♡ 0