Wardn HubTrusted MCP server directory.

Registry

  • MCP Servers
  • Skills
  • Categories

Resources

  • API docs
  • Score method

Contribute

  • Submit server
  • Advertise
© 2026 Wardn Hub
Wardn Hub
MCP ServersSkillsCategoriesAPI docsSubmit server
Submit server
skills/mohitagw15856/pm-claude-skills/security-review

security-review

1
mohitagw15856/pm-claude-skills·Audit passed·Snapshot 1c682bd8d33d

Summary

This source did not publish a separate summary. Review SKILL.md before using the skill.

SKILL.md

Security Review Skill

A security review is a focused pass for the ways a change could be abused — before it reaches production. This skill reviews a design, PR, or feature against the recurring risk areas, ranks findings by severity, and gives a clear verdict with concrete fixes. It's for code/systems you own or are authorized to review, and it complements (not replaces) automated scanners and a formal pentest.

Required Inputs

Ask for these only if they aren't already provided:

  • What's under review — the design/diff/feature, and what it does.
  • Context — the stack, where it runs, what data/permissions it touches, who can reach it (internet-facing? authenticated?).
  • Sensitivity — the assets involved (PII, credentials, money, admin capability) and the threat context.

Output Format

Security review: [change/feature]

Summary & verdict — one-line read and a call: ✅ ship / 🔁 fix-first / ⛔ block, with the gating issue(s).

Review by risk area — scan each and note findings:

  1. AuthN / AuthZ — is identity verified, and is every action authorized (incl. object-level / IDOR, privilege escalation)?
  2. Input handling — validation/encoding; injection (SQL/command/template), SSRF, path traversal, deserialization, XSS.
  3. Secrets & crypto — hard-coded secrets, key handling, weak/absent crypto, tokens in logs/URLs.
  4. Data exposure — over-broad responses, PII in logs/errors, missing encryption in transit/at rest, verbose errors.
  5. Dependencies & config — known-vuln libraries, insecure defaults, missing security headers, CORS, permissions.
  6. Abuse & availability — rate-limiting, resource exhaustion, business-logic abuse, missing audit logging.

Findings (ranked) — each with severity, where, why it's exploitable, and the fix:

SeverityAreaFinding (how it's exploited)Fix
🔴 Critical/High
🟡 Medium
🔵 Low / hardening

What's done well — controls already in place (so they're kept).

Follow-ups — anything needing a scanner, a pentest, or a deeper look.

Quality Checks

  • Every standard risk area is considered (authz incl. IDOR, input/injection, secrets, data exposure, deps, abuse)
  • Findings are ranked by severity with a concrete, actionable fix each
  • Exploitability is explained — why it's a real issue in this context, not a generic warning
  • A clear ship / fix-first / block verdict names the gating issues
  • Existing good controls are acknowledged; deeper follow-ups (scanner/pentest) are flagged

Anti-Patterns

  • Do not produce a generic checklist — tie each finding to this code/design and its exploit path
  • Do not rank everything the same — separate critical from hardening nits
  • Do not report an issue without a fix — give the concrete remediation
  • Do not miss authorization (IDOR/privilege) — it's the most common real-world web flaw
  • Do not review code you don't own or aren't authorized to assess

Based On

Secure code/design review practice (OWASP Top 10 & ASVS risk areas, severity-ranked findings, actionable remediation).

Related skills

capacity-planningcompetitor-teardowncontext-engineering-reviewrunbook-writerreceipts-audit