api-security-guard
Skill1 starsChanged 8 days agoMITView on GitHub
Audit, harden and monitor an API against 12 rules - authenticate every call, check object access, rate limit, validate input, HTTPS only, short-lived tokens, least-privilege keys, no secrets in URLs, log auth failures, version the API, limit response data, inventory endpoints. Includes an endpoint inventory scanner and monitoring alerts. Use when asked to review API security, check for BOLA/IDOR, list all endpoints, or build API monitoring. Use proactively whenever you add or change an API route, authentication or a token.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Abdox-menara/guard-skillstheir own version, first seen Aug 24, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Abdox-menara/guard-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository8 other files it gives its agents.
- skills/zero-trust-review/references/agents.mdAGENTS.md
- app-readiness-auditSkill
- build-flow-mapSkill
- monitor-alerts-builderSkill
- motionsiteSkill
- session-journalSkill
- skeletonizerSkill
- zero-trust-reviewSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Runs on its own: when Claude adds or changes a route, auth or a token, it checks the change against the 12 rules, and edited files are …
- Distinctive: line 33
Inventory first (rule 12): Run:
- Very specific: line 42
Monitor: Add the alerts from references/monitoring.md using the monitor-alerts-builder skill if installed.
- Distinctive: line 43
Keep the inventory alive: Commit the OpenAPI spec (or the inventory output), and fail CI when a route exists in code but not in the spec.
- Distinctive: line 47
Read code and configs. Do not send requests to any live system you do not own, and do not run exploit or fuzzing tools unless the user owns …
- Distinctive: line 48
Never print real tokens or keys.
- Distinctive: line 49
If a secret was exposed in a URL or log, say it must be rotated.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
API Security Guard
Checks an API against 12 rules (mapped to the OWASP API Security Top 10, 2023), builds the missing protections, and sets up monitoring so attacks and drift are noticed.
Runs on its own: when Claude adds or changes a route, auth or a token, it checks the change against the 12 rules, and edited files are scanned for hard-coded secrets, wildcard CORS, secrets in URLs and turned-off TLS checks.
The 12 rules
| # | Rule | OWASP API 2023 | Core question |
| 1 | Authenticate every call | API2 | Is there any route a stranger can call that should not be public? |
| 2 | Check object access | API1, API5 | Can user A read or change user B's record by changing an ID? Can a normal user call an admin function? |
| 3 | Rate limit | API4, API6 | Are login, reset, search, and costly or business-critical flows throttled? |
| 4 | Validate input | API3, API7 | Is every field type-checked, size-limited, allow-listed at the boundary? Any server-side fetch of user URLs? |
| 5 | HTTPS only | API8 | Redirect or reject plain HTTP? HSTS? No plain-text tokens? |
| 6 | Short-lived tokens | API2 | Access tokens in minutes, refresh tokens rotated and revocable? |
| 7 | Least-privilege keys | API5, API8 | Keys and service accounts scoped to read-only or minimum permissions? |
| 8 | No secrets in URLs | API8 | Any ?token=, ?api_key= in routes, links or clients? |
| 9 | Log auth failures | API8 | 401/403/lockouts logged with IP, user, route, and alerted on spikes? |
| 10 | Version your API | API9 | Are old versions tracked, deprecated with dates, and retired? |
| 11 | Limit response data | API3 | Only needed fields returned? No hashes, internal IDs, or other users' data? Pagination caps? |
| 12 | Inventory endpoints | API9, API10 | Is there a current list of every endpoint, including old, internal, debug and third-party ones? |
Details, how to verify and fix each rule: references/rules.md. Alerts for each: references/monitoring.md.
Procedure
- Inventory first (rule 12). Run:
It lists routes with auth evidence, version, object-ID parameters, and spec/code drift, and flags tokens in URLs, plainpython3 <skill-dir>/scripts/api_inventory.py <project-root> > /tmp/api-inventory.mdhttp://, long-lived tokens and data-exposure leads. Read its limits: it is heuristic. "none seen" means no auth pattern matched near the route. Apps with custom auth wrappers will show false alarms, so check how auth is actually applied (middleware, router-level dependency, gateway) and tell the user. - Verify by reading code. For every route flagged
none seen, open it and decide: public by design, protected elsewhere (gateway, router-level), or a real gap. For every route with an object-ID parameter, find the line that proves the record belongs to the caller (a query filtered by the user or tenant, or a policy check). No such line means a probable BOLA/IDOR: rule 2 FAIL. - Walk the 12 rules using
references/rules.md; rate eachPASS / WARN / FAIL / UNKNOWNwithpath:lineevidence. Items needing infrastructure access (gateway config, TLS termination, key scopes in a cloud console) areUNKNOWN, listing exactly where to look. - Report in this order: broken access control (rules 1, 2) first, then credentials and transport (5, 6, 7, 8), then abuse and data exposure (3, 4, 11), then visibility (9, 10, 12).
- Fix one finding at a time, smallest safe change, and add a test that proves the fix (for rule 2: a test where user B requests user A's object and gets 403 or 404).
- Monitor. Add the alerts from
references/monitoring.mdusing themonitor-alerts-builderskill if installed. At minimum: auth-failure spike, 403/404 probing per user, rate-limit hits, traffic on deprecated versions, and requests to routes not in the inventory. - Keep the inventory alive. Commit the OpenAPI spec (or the inventory output), and fail CI when a route exists in code but not in the spec.
Rules of engagement
- Read code and configs. Do not send requests to any live system you do not own, and do not run exploit or fuzzing tools unless the user owns the target and asks.
- Never print real tokens or keys; show the first 4 characters and the location.
- If a secret was exposed in a URL or log, say it must be rotated.
- A clean scan is not proof of security. Say so in the summary.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.