Skip to content
Back to skills

Security Audit

ASecurity

A focused hunt for exploitable weaknesses — `quality:security`, `quality:qa suite=security`

  • 3 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 1, 2026
ai-agentsrustgosqlgitapidatabasebackendci/cdsecurity

Works with

  • cli
  • api

Security analysis

A100/100

Scanned October 1, 2026

npx -y skills add sharmapuneet1510/awesome-prompts --skill security-audit --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Security Audit?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Security Audit
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/sharmapuneet1510-security-audit/badge)](https://www.skillsdirectory.com/skills/sharmapuneet1510-security-audit)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: security-audit
description: A focused hunt for exploitable weaknesses — `quality:security`, `quality:qa suite=security`
---

# Security Audit Skill — v1.1

## Quick Card

> Read this card first. Load a section below only when the task needs it.

| | |
|---|---|
| **Use when** | A focused hunt for exploitable weaknesses — `quality:security`, `quality:qa suite=security` |
| **Skip when** | General style review — `code_review_skill` |
| **Inputs** | Entry points, trust boundaries, dependency lockfiles |
| **Produces** | Findings with OWASP category, file:line, severity, concrete fix |
| **Steps** | 1. Walk every entry point → 2. Check every trust boundary → 3. OWASP Top 10 pass → 4. Grade by exploitability → 5. Concrete fix per finding |
| **Done when** | §5 checklist passes; no finding without file:line and a specific fix |
| **Load on demand** | §1 scope · §2 OWASP checklist · §3 severity · §4 fix discipline |
| **Run report** | `html_report_skill` — adds: Findings by severity × OWASP category |
| **Pairs with** | `code_health_skill`, `backend_skill`, `nemesis_skill` |

---

## 1. Audit Scope

A security audit is a focused pass, distinct from a general code review: look specifically for exploitable weaknesses, not style or structure. Walk every external-input entry point (HTTP handlers, message consumers, file uploads, CLI args) and every trust boundary (auth, tenant isolation, admin vs. user).

## 2. OWASP Top 10 Checklist (Web/API Context)

For each finding, note: category, file:line, severity, and a concrete fix.

1. **Broken Access Control** — missing authorization checks, IDOR (object references not scoped to the requesting user/tenant), privilege escalation paths.
2. **Cryptographic Failures** — secrets/PII in plaintext, weak hashing (MD5/SHA1 for passwords instead of bcrypt/argon2), hardcoded keys.
3. **Injection** — string-concatenated SQL/NoSQL/OS commands, unescaped template output (XSS), unsafe deserialization.
4. **Insecure Design** — missing rate limiting on auth endpoints, no account lockout, business logic that trusts client-side validation alone.
5. **Security Misconfiguration** — verbose error messages leaking stack traces to clients, default credentials, permissive CORS (`*` with credentials).
6. **Vulnerable Components** — outdated dependencies with known CVEs; check lockfiles against an advisory database.
7. **Auth Failures** — session tokens that don't expire, predictable session IDs, missing MFA on privileged actions.
8. **Data Integrity Failures** — unsigned/unverified deserialization, CI/CD pipelines pulling unpinned dependencies.
9. **Logging/Monitoring Failures** — auth failures and privilege changes not logged; secrets logged in plaintext.
10. **SSRF** — server-side requests built from user-supplied URLs without an allowlist.

## 3. Severity Grading

- **Critical** — remotely exploitable, no auth required, leads to data breach or full compromise (e.g., unauthenticated SQLi, broken access control on admin routes).
- **High** — exploitable with some precondition (authenticated user, specific role) but still leads to significant impact (IDOR exposing other users' data).
- **Medium** — requires a harder-to-reach precondition or has limited impact (reflected XSS behind an unusual input path).
- **Low** — defense-in-depth gaps (missing security headers, verbose but non-sensitive error messages).

## 4. Fix Discipline

Every finding needs a concrete fix, not just "sanitize input":
- Injection → parameterized queries / prepared statements, not string escaping.
- Broken access control → check ownership/tenant scope server-side on every request, not just at the UI layer.
- Secrets → move to a secrets manager / environment variable, rotate the exposed value, add a pre-commit secret scanner.

## 5. Checklist

✅ Every external-input entry point walked
✅ Every trust boundary checked for authorization enforcement
✅ Findings graded by actual exploitability, not just "it's a smell"
✅ Each finding has file:line and a concrete fix, not a vague recommendation
✅ Dependency versions checked against known CVEs
✅ No secrets/PII in logs or error responses

---
> Inspired by ideas from [ai-boost/awesome-prompts](https://github.com/ai-boost/awesome-prompts) (GPL-3.0) — content rewritten, not copied. See `docs/reference/credits.md`.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…