Api security
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill api-securityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 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.
- 4 stars4 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
Secure an API by enforcing per-object authorization, per-caller quota, and schema-validated input on every endpoint. Use when building or reviewing an HTTP or GraphQL API that serves authenticated users, machine clients, or partner integrations.
SKILL.md
2.9 KB, as published. Nobody here has run it
API security
Every endpoint makes a silent promise about who may touch which object and in what shape. The flaws that dominate the OWASP API Top 10 are dull, not clever: a handler that trusts the ID in the path, a parser that swallows fields it was never told about, an endpoint with no ceiling that one client drains. Each one ships green through functional tests and breaks on the first deliberate probe.
Method
- Authorize the object, not only the route. Once the caller is
authenticated, verify this caller may access this exact record before you
return it.
GET /invoices/5567must confirm invoice 5567 belongs to the token's tenant. Broken object-level authorization (BOLA) is the most exploited API flaw, and route middleware never sees the record ID. - Validate the body against a closed schema. Model every request with
Zod, Pydantic, or JSON Schema that pins types, formats, bounds, and
additionalProperties: false. Reject unknown keys outright so a client cannot slipis_admin: trueinto a profile update that mass-assigns. - Serialize through an output allowlist. Build responses from an explicit
field list, never the raw ORM row. Dumping the whole record leaks
password_hash, internal flags, and columns from joined tables. - Meter every caller and weight expensive calls. Give each token a rate bucket, charge search and export more than a point read, and cap page size and GraphQL query depth so one call cannot pull 50,000 rows or nest resolvers without limit.
- Issue machine clients scoped, expiring credentials. Grant API keys or OAuth client-credentials the narrowest scopes the integration uses, set an expiry, and support rotation with overlap. One omnipotent static key is a single leak away from full compromise.
- Return errors that say nothing extra. Send 401 versus 403 correctly but keep bodies generic: no stack traces, no SQL fragments, no "wrong password" message that confirms an account exists.
Checks
- Does requesting another tenant's object ID return 403 rather than the data?
- Does a body with one unexpected field get rejected, not silently accepted?
- Does a scripted loop actually hit a per-caller quota and get throttled?
- Do 500 responses omit stack traces and internal identifiers?
Boundaries
This covers authorization, input, and quota at the application layer. It does not replace transport security (see tls-configuration), a gateway's network controls, or the identity provider that mints tokens. Framework defaults rarely enforce object-level checks: assume you write those by hand.