
Owasp Security Check
Run a structured REST API security pass for mass assignment, pagination, validation, versioning, response shape, and rate limits before ship or after API changes.
Overview
owasp-security-check is an agent skill most often used in Ship (also Build/backend) that audits REST APIs for mass assignment, pagination, validation, versioning, and rate-limit gaps.
Install
npx skills add https://github.com/sergiodxa/agent-skills --skill owasp-security-checkWhat is this skill?
- Checklist covers mass assignment, pagination, Content-Type validation, API versioning, and response data minimization
- Documents bad patterns for unbounded list endpoints and blind req.json() updates
- Cross-links injection, authentication-failures, and rate-limiting companion checks
- REST-focused patterns in TypeScript-style examples
- Impact tagged MEDIUM in SKILL frontmatter
- 6-item what-to-check checklist
- Impact MEDIUM in skill metadata
Adoption & trust: 967 installs on skills.sh; 88 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your REST handlers accept raw JSON and unbounded queries, so users could flip admin fields or drain the database through a single list endpoint.
Who is it for?
Solo developers exposing Admin or public REST/JSON APIs in TypeScript or similar stacks who want OWASP-aligned review cues without hiring a firm first.
Skip if: GraphQL-only services, mobile binary protocols, or teams that already finished a formal pen test with signed attestation—this is pattern guidance, not certification.
When should I use this skill?
User is reviewing or implementing REST API routes and needs OWASP-aligned checks for mass assignment, pagination, validation, versioning, response size, or rate limits.
What do I get? / Deliverables
You get a prioritized pass against documented bad patterns and checklist items so updates whitelist fields, paginate lists, validate Content-Type, version routes, trim responses, and align rate limits before merge.
- Security findings mapped to checklist items
- Remediation notes for vulnerable patterns
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is ship/security because the skill is an OWASP-style gate before production exposure of HTTP APIs. Security subphase is where mass-assignment and resource-exhaustion findings are meant to be caught and remediated.
Where it fits
Before merging a PATCH /users handler, verify the body cannot set isAdmin or role fields.
Pre-release sweep ensuring every list route enforces pagination and rate limits.
After an incident report on API scraping, re-check versioning and response field exposure.
How it compares
Structured API security checklist skill, not a live OWASP ZAP MCP server or dependency SCA scanner.
Common Questions / FAQ
Who is owasp-security-check for?
Indie backend builders and agent users shipping REST APIs who need consistent review for assignment, pagination, and abuse vectors aligned with OWASP API thinking.
When should I use owasp-security-check?
Use it in ship/security before launch on new routes; in build/backend when scaffolding updateUser or list endpoints; and after refactors that touch request bodies or list queries.
Is owasp-security-check safe to install?
It is procedural documentation—review the Security Audits panel on this Prism page and treat findings as guidance you still validate in your own codebase.
SKILL.md
READMESKILL.md - Owasp Security Check
# REST API Security Check for REST API vulnerabilities including mass assignment, lack of validation, and missing resource limits. > **Related:** Input validation in [injection-attacks.md](injection-attacks.md). Authentication in [authentication-failures.md](authentication-failures.md). Rate limiting in [rate-limiting.md](rate-limiting.md). ## Why - **Mass assignment**: Users modify protected fields - **Over-fetching**: Expose unnecessary data - **Resource exhaustion**: Unlimited result sets - **API abuse**: Missing versioning and documentation ## What to Check - [ ] Mass assignment in update operations - [ ] No pagination on list endpoints - [ ] Missing Content-Type validation - [ ] No API versioning - [ ] Excessive data in responses - [ ] Missing rate limits ## Bad Patterns ```typescript // Bad: Mass assignment async function updateUser(req: Request): Promise<Response> { let session = await getSession(req); let data = await req.json(); // VULNERABLE: User can set isAdmin, role, etc.! await db.users.update({ where: { id: session.userId }, data, // Dangerous - accepts all fields! }); return new Response("Updated"); } // Bad: No pagination async function getUsers(req: Request): Promise<Response> { // VULNERABLE: Could return millions of records let users = await db.users.findMany(); return Response.json(users); } // Bad: No input validation async function createPost(req: Request): Promise<Response> { let data = await req.json(); // VULNERABLE: No validation of data types or values await db.posts.create({ data }); return new Response("Created", { status: 201 }); } ``` ## Good Patterns ```typescript // Good: Explicit field allowlist async function updateUser(req: Request): Promise<Response> { let session = await getSession(req); let body = await req.json(); let allowedFields = { displayName: body.displayName, bio: body.bio, avatar: body.avatar, }; if ( allowedFields.displayName && typeof allowedFields.displayName !== "string" ) { return new Response("Invalid displayName", { status: 400 }); } await db.users.update({ where: { id: session.userId }, data: allowedFields, }); return new Response("Updated"); } // Good: Pagination with limits async function getUsers(req: Request): Promise<Response> { let url = new URL(req.url); let page = parseInt(url.searchParams.get("page") || "1"); let limit = Math.min(parseInt(url.searchParams.get("limit") || "20"), 100); let users = await db.users.findMany({ take: limit, skip: (page - 1) * limit, }); return Response.json({ data: users, page, limit }); } // Good: Input validation async function createPost(req: Request): Promise<Response> { let session = await getSession(req); let body = await req.json(); if ( !body.title || typeof body.title !== "string" || body.title.length > 200 ) { return new Response("Invalid title", { status: 400 }); } if ( !body.content || typeof body.content !== "string" || body.content.length > 50000 ) { return new Response("Invalid content", { status: 400 }); } await db.posts.create({ data: { title: body.title, content: body.content, authorId: session.userId, }, }); return new Response("Created", { status: 201 }); } ``` ## Rules 1. **Prevent mass assignment** - Explicitly define allowed fields 2. **Always paginate lists** - Enforce maximum page size 3. **Validate input types** - Check types and constraints 4. **Version your API** - Use `/api/v1/` prefix for versioning 5. **Limit response data** - Return only necessary fields 6. **Validate Content-Type** - Ensure correct headers --- title: Authentication Failures impact: CRITICAL tags: [authentication, passwords, mfa, sessions, owasp-a07] --- # Authentication Failures Check for weak authentication mechanisms, missi