Security review
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill security-reviewAssembled 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
Review code for the vulnerabilities that actually get exploited, ranked by real risk with concrete attack scenarios. Use when reviewing changes that touch input handling, auth, secrets, files, queries, or network calls.
SKILL.md
2.6 KB, as published. Nobody here has run it
Security review
Audit the paths an attacker would walk, not a checklist. Every finding needs a concrete attack scenario; if you cannot describe the attack, it is a hardening suggestion, not a vulnerability.
Method
- Map the trust boundaries first. Where does data enter from outside (requests, files, env, third-party APIs, user uploads)? Where does the code do something privileged (queries, shell, filesystem, network, crypto, money)? Vulnerabilities live on paths from the first list to the second.
- Walk each path hunting the classics, in payoff order:
- Injection: user input reaching SQL, shell, path, template, or eval without parameterization or strict validation. String concatenation into any interpreter is guilty until proven safe.
- Broken auth and authz: endpoints missing permission checks, ids taken from the client without ownership verification (IDOR), tokens that never expire, secrets compared with string equality.
- Secrets in the wrong place: keys in code, tokens in logs, credentials in error messages or URLs.
- Unsafe deserialization and parsing of untrusted data.
- SSRF: user-influenced URLs fetched by the server without a host allowlist; redirects and DNS tricks bypass naive checks.
- Path traversal: filenames from users joined into paths without canonicalization checks.
- Missing limits: unbounded sizes, counts, depths, and rates, each a denial of service on a timer.
- Verify each candidate. Construct the input and the resulting damage: "a filename of ../../etc/cron.d/x writes outside the upload dir". If the framework already neutralizes it, say so and move on; false alarms erode trust in real ones.
- Rank by exploitability times damage. Remote unauthenticated beats authenticated; data theft and code execution beat information leaks. Report the worst first, with the fix that closes the class, not just the instance: parameterize everywhere, not just this query.
Rules
- Never write working exploit payloads into the report beyond the minimum needed to demonstrate the flaw to the maintainer.
- Dependency risk counts: flag known-vulnerable versions when visible, but do not speculate about CVEs from memory without checking.
- Absence of findings is a real result. Say "no injection paths found in the reviewed surface" and name what you did not review.