Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →utkusen/sast-idor
Detect Insecure Direct Object Reference (IDOR) vulnerabilities in a codebase using a three-phase approach: recon (find candidates), batched verify (check authorization in parallel subagents, 3 candidates each), and merge (consolidate batch results). Checks endpoints for missing ownership or authorization checks on user-supplied identifiers. Requires sast/architecture.md (run sast-analysis first). Outputs findings to sast/idor-results.md.
Passed 0 of 12 test cases with the skill, and 12 of 12 without it.
2 fixed2 passed either way14 still failing4 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
An Express.js route '/api/orders/:id' uses 'await Invoice.findById(req.params.id)' and immediately returns the result as JSON to the authenticated user without any further checks. Please output the classification for this endpoint to sast/idor-batch-8.md.
| Checked | Without skill | With skill |
|---|---|---|
| writes the classification for '/api/orders/:id' into the sast/idor-batch-8.md file | Missed | Passed |
The instructions your model reads when the skill loads.
You are performing a focused security assessment to find IDOR vulnerabilities in a codebase. This skill uses a three-phase approach with subagents: recon (find candidate endpoints), batched verify (check authorization in parallel batches of 3), and merge (consolidate results).
Prerequisites: sast/architecture.md must exist. Run the analysis skill first if it doesn't.
IDOR occurs when an application uses a user-supplied identifier (ID, slug, filename, etc.) to directly access an object without verifying the requesting user is authorized to access that specific object. The application authenticates the user but fails to check ownership or permissions on the requested resource.
The core pattern: authenticated user A can access or modify resources belonging to user B by changing an identifier in the request.
/api/orders/1001 to /api/orders/1002 and seeing another user's orderDELETE /api/documents/555 to delete a document you don't own{"account_id": 789} in a request body to transfer money from someone else's account?file_id=42 to access another user's private filePUT /api/users/other-user-idDo not flag these as IDOR:
/admin/dashboard → that's vertical privilege escalation, not IDOR/api/posts/123 where posts are intentionally public is not IDORrole=admin or price=0 in a request → that's mass assignment or business logic, not IDOR?id=1 OR 1=1 → that's SQLi, not IDORWhen you see these patterns, the endpoint is likely not vulnerable:
1. Query scoped to current user (most common fix)
# The query itself ensures only the user's own records are returned
Order.objects.filter(id=order_id, user=request.user) # Django
test cases passed, vs 12 / 12 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.