Rate Limit Validator

Test whether an HTTP endpoint enforces rate limiting. Sends a burst of requests and checks for 429 responses, Retry-After, and X-RateLimit headers. Useful fo...

Security Scan

The skill's requirements and instructions match its stated purpose of testing HTTP rate limiting, with only minor inconsistencies and operational caveats to be aware of.

Purpose & Capability

Name and description match the runtime instructions: the SKILL.md provides a simple curl-based script to send a burst of GETs and check for 429 and rate-limit headers. The requested binary (curl) is appropriate for the stated task.

Instruction Scope

The runtime script sends repeated requests to a target and checks headers — this stays within the stated purpose. However the script assumes additional utilities (bash, seq, grep, rm) that are not listed in requires.bins. The SKILL.md explicitly notes this is for testing your own deployments, but the instructions do not enforce or verify authorization — an operator must ensure they have permission to test a remote service to avoid abuse/DoS.

Install Mechanism

Instruction-only skill with no install steps or external downloads. This minimizes supply-chain risk.

Credentials

No environment variables, credentials, or config paths are requested. The level of requested access is proportionate to the stated purpose.

Persistence & Privilege

The skill does not request permanent presence (always: false) or modify other skills or system configs. It runs ad-hoc tests as expected.

Assessment

This skill is coherent and lightweight, but review these practical points before using it: - Ensure you have explicit permission to run burst tests against the target (testing third-party services without authorization can be abusive or illegal). - The script declares curl as required but also calls bash, seq, grep, and rm; make sure those are available on the host or add them to the declared dependencies. - The provided test is sequential (not concurrent); depending on the gateway's throttling rules you may need to run concurrent requests to trigger rate limits — but increasing concurrency or request count can cause downtime. Start with low counts and increase cautiously. - The header check performs a separate HEAD request; some services only surface rate-limit headers on actual application requests or per-authenticated user, so interpret results accordingly. - Consider running tests from the same client/IP and authentication context the real clients use, as rate limits are often per-IP, per-user, or per-API-key. If you want higher assurance about safety or intended behavior, ask the skill publisher to: (1) list all binaries the script relies on, (2) add an explicit concurrency option, and (3) include a clear authorization/ethics notice in SKILL.md.

Tests whether an HTTP endpoint actually enforces rate limiting.

Most rate-limit skills help you add rate limiting. This one helps you check if it's working — or if it's missing entirely.

What it checks

• Whether the server returns HTTP 429 under burst load
• Presence of Retry-After header
• Presence of X-RateLimit-Limit and X-RateLimit-Remaining headers
• Response time degradation under sustained requests

When to use it

• Before deploying an API or gateway to production
• After adding rate-limit middleware, to confirm it works
• When auditing a third-party service you depend on
• Validating threat model mitigations (e.g. T-IMPACT-002)

Example prompts

• "Test if my gateway has rate limiting"
• "Validate rate limiting on http://localhost:18789"
• "Check if my API throttles requests"

Test script

#!/bin/bash
TARGET="${1:-http://localhost:18789/}"
COUNT="${2:-50}"
TMP="/tmp/ratelimit-test-$$.txt"

echo "Target: $TARGET"
echo "Requests: $COUNT"
echo ""

for i in $(seq 1 $COUNT); do
  curl -s -o /dev/null -w "%{http_code}" "$TARGET" >> "$TMP"
  echo "" >> "$TMP"
done

TOTAL_200=$(grep -c '200' "$TMP" || echo 0)
TOTAL_429=$(grep -c '429' "$TMP" || echo 0)

echo "Allowed (200): $TOTAL_200"
echo "Throttled (429): $TOTAL_429"
echo ""

HEADERS=$(curl -sI "$TARGET")
echo "$HEADERS" | grep -qi "retry-after" && echo "Retry-After: present" || echo "Retry-After: missing"
echo "$HEADERS" | grep -qi "x-ratelimit" && echo "X-RateLimit: present" || echo "X-RateLimit: missing"

echo ""
if [ "$TOTAL_429" -gt 0 ]; then
  echo "Result: rate limiting is active ($TOTAL_429/$COUNT throttled)"
else
  echo "Result: no rate limiting detected ($TOTAL_200/$COUNT allowed through)"
fi

rm -f "$TMP"

Notes

• Only sends GET requests, no payloads
• Meant for testing your own deployments, not for attacking others
• In OpenClaw's trust model, rate limiting is a hardening measure, not a security boundary (authenticated callers are trusted operators)

References

• OpenClaw threat model (T-IMPACT-002)
• OpenClaw security policy