Api security
AppSec Skills — 15 plug-and-play Claude Code security skills that audit, harden, and fix any website or app before you ship it. OWASP Top 10, auth, API, database, frontend, backend, cloud, dependencies, secrets, and pentest-style checks — all defensive, all evidence-based.
npx -y skills add Rootx202/appsec-skills --skill api-securityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 23 days oldThe repository was created 23 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Focused API security auditor for REST, GraphQL, and webhook endpoints in any stack. Use when the user is building or reviewing an API layer, mentions rate limiting, API keys, webhooks, CORS, or specifically wants "API security" checked — as opposed to a full-project audit.
SKILL.md
2.7 KB, as published. Nobody here has run it
API Security — API Layer Auditor
A specialized skill for auditing the security of the API surface (REST/GraphQL/Webhooks) independent of the rest of the project.
When to use this
- Reviewing API routes/controllers in any framework (Express, FastAPI, NestJS, Next.js API routes, Django REST Framework, Spring, etc.)
- Reviewing incoming/outgoing webhook design
- Reviewing API key issuance for external clients or partners
Core Checks
Authorization at Every Endpoint
- For each route: who is allowed to access it? Is there actual enforcement, or just a
// TODO: add authcomment? - GraphQL: check that introspection isn't exposed in production, and that query depth/complexity limiting exists to prevent nested-query denial-of-service.
Rate Limiting
- Is every sensitive endpoint (login, OTP, search, checkout, password reset) protected by a rate limiter (Redis-backed or equivalent)?
- Is the limit keyed on IP alone (easy to bypass) or combined with user/device identity?
CORS
- Is
Access-Control-Allow-Origin: *combined withcredentials: true? (Always Critical.) - Explicit allow-list of origins instead of accepting everything.
Input Validation at API Boundaries
- Strict schema validation (zod/joi/pydantic/class-validator) on every body/query/params
- Rejects unexpected extra fields (mass-assignment protection)
Webhooks
- Incoming webhook signature (HMAC) verified before processing — never trust an unsigned webhook payload
- Nonce/timestamp used to prevent replay attacks
Error Handling & Responses
- Correct HTTP status codes (401 vs 403 vs 404) without leaking information through inconsistency (e.g., returning 404 for an existing-but-unauthorized resource vs. 403 may be an intentional anti-enumeration choice — call out the tradeoff for the given context)
- No stack traces or internal details returned in production responses
API Keys for External Clients
- Keys hashed/stored securely in the database (never plaintext)
- Revocation and rotation supported
- Scoped permissions per key instead of always granting full access
Report Format
Endpoint: METHOD /path
Issue: [name]
Severity: Critical/High/Medium/Low
Evidence: [code or observed behavior]
Impact: [impact]
Fix: [suggested remediation]
Rules
- Stay focused on the API boundary; hand off database-layer issues to
database-security. - Don't produce ready-to-use attack payloads — describe the issue and impact scenario briefly instead.