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...

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.

Type: OpenClaw Skill Name: rate-limit-validator Version: 1.0.0 The skill's stated purpose is benign (testing rate limiting). However, the `SKILL.md`'s bash script directly uses user-provided input (`$TARGET`) in `curl` commands without explicit sanitization. While `curl` is generally robust when URLs are properly quoted, this represents a lack of input sanitization, creating a potential shell injection vulnerability if a malicious user crafts the `TARGET` argument. There is no evidence of intentional malicious behavior, but the vulnerability makes it suspicious.