agentleFS
derHakenderHaken/SuperAntigravity/skills/security-review/SKILL.md

security-review

Skill439 starsChanged 8 months agoMITView on GitHub

Use when reviewing code for vulnerabilities, implementing authentication or authorization, handling user input, storing sensitive data, or before any feature that touches security boundaries goes to production

  • Reads credentials

We split this skill into the rules it gives an agent

9 rules. 0 are common, 3 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 167 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before a security-sensitive feature ships

    line 18
  2. Distinctive:

    After any change to auth flows or data access controls

    line 19
  3. Very specific:

    Search: grep -rn 'req\.params\.id\|req\.query\.id' --include='*.js' --include='*.ts' — verify each result checks ownership

    line 29
  4. Very specific:

    Search: grep -rn 'query\s*[+\].*\(req\.\|user\.\|input\|params\)' --include='*.js' --include='*.ts' --include='*.py'`

    line 46
  5. Very specific:

    Run: npm audit or pip-audit or snyk test

    line 71
  6. Very specific:

    Run: npm audit --audit-level=high (exits non-zero if high/critical found)

    line 73
  7. Very specific:

    Search: grep -E '"\^|"~|">=|">' package.json — each result is a non-pinned dependency

    line 77
  8. Very specific:

    Search: grep -rn 'reset.*token\|token.*reset' --include='*.js' --include='*.ts' --include='*.py' — verify expiry and single-use enforcement

    line 83
  9. Distinctive:

    If no vulnerabilities found: output "Security Review: PASS.

    line 130

“Common” is measured: kept by at least 6 in 10 of the 167 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Security Review

Overview

Security is not a feature — it's a property of the entire system. Review security boundaries systematically, not ad-hoc.

When to Use

  • Authentication, authorization, session management code
  • Any user input that touches storage, commands, or rendering
  • Secrets, credentials, API keys in code or config
  • Before a security-sensitive feature ships
  • After any change to auth flows or data access controls

OWASP Top 10 Checklist

Work through these for every security-relevant code change:

A01 - Broken Access Control

  • Every endpoint checks authorization, not just authentication
    • Search: grep -r 'router\.\|app\.\(get\|post\|put\|delete\|patch\)' --include='*.js' --include='*.ts' | grep -v 'auth\|authorize\|permission\|role'
  • Users can only access their own data
    • Search: grep -rn 'req\.params\.id\|req\.query\.id' --include='*.js' --include='*.ts' — verify each result checks ownership
  • Admin functions require explicit admin role check
    • Search: grep -rn 'admin' --include='*.js' --include='*.ts' | grep -v 'isAdmin\|requireAdmin\|role.*admin\|admin.*role'

A02 - Cryptographic Failures

  • No secrets in source code or env files committed to git
    • Search: grep -rn 'password\s*=\s*["\x27][^"\x27]\|api_key\s*=\s*["\x27][^"\x27]\|secret\s*=\s*["\x27][^"\x27]' --include='*.js' --include='*.py' --include='*.ts'
  • Passwords hashed with bcrypt/argon2 (not MD5/SHA1)
    • Search: grep -r 'password' --include='*.js' --include='*.ts' --include='*.py' | grep -v 'bcrypt\|argon2\|hash'
    • Also check: grep -rn 'md5\|sha1\|sha256' --include='*.js' --include='*.ts' --include='*.py' | grep -i 'password'
  • Data in transit uses TLS
    • Search: grep -rn 'http://' --include='*.js' --include='*.ts' --include='*.py' | grep -v 'localhost\|127\.0\.0\.1\|test\|spec\|comment'
  • Sensitive data not logged
    • Search: grep -rn 'console\.log\|logger\.' --include='*.js' --include='*.ts' | grep -i 'password\|token\|secret\|key\|ssn\|credit'

A03 - Injection

  • All database queries use parameterized queries / ORM (never string concat)
    • Search: grep -rn 'query\s*[+\].(req.|user.|input|params)' --include='.js' --include='.ts' --include='.py'`
    • Also: grep -rn '"SELECT\|"INSERT\|"UPDATE\|"DELETE' --include='*.js' --include='*.ts' | grep '\+'
  • All shell commands use safe exec (never eval with user input)
    • Search: grep -rn 'eval(\|exec(\|system(\|spawn(' --include='*.js' --include='*.ts' --include='*.py'
  • All HTML output is escaped or uses safe template engine
    • Search: grep -rn 'innerHTML\s*=' --include='*.js' --include='*.ts' | grep -v '//.*innerHTML'

A04 - Insecure Design

  • Authentication flows validated against known-good patterns
  • Rate limiting on authentication endpoints
    • Search: grep -rn 'login\|signin\|auth' --include='*.js' --include='*.ts' | grep -v 'rateLimit\|rate_limit\|throttle'
  • Account enumeration prevented (same response for unknown user vs wrong password)
    • Search: grep -rn '"User not found"\|"Invalid username"\|"No account"' --include='*.js' --include='*.ts' --include='*.py'

A05 - Security Misconfiguration

  • Debug mode disabled in production
    • Search: grep -rn 'debug\s*=\s*true\|DEBUG\s*=\s*True\|NODE_ENV.*development' --include='*.js' --include='*.ts' --include='*.py' --include='*.env'
  • Default credentials changed
    • Search: grep -rn 'admin.*admin\|root.*root\|password.*password\|default.*password' --include='*.js' --include='*.ts' --include='*.py'
  • Unnecessary features/endpoints disabled
  • Error messages don't expose stack traces to users
    • Search: grep -rn 'err\.stack\|error\.stack\|traceback' --include='*.js' --include='*.ts' --include='*.py' | grep -v 'log\|console\|logger'

A06 - Vulnerable and Outdated Components

  • Dependencies checked against known CVE databases (npm audit, pip-audit, snyk)
    • Run: npm audit or pip-audit or snyk test
  • No dependencies with known critical/high CVEs in production
    • Run: npm audit --audit-level=high (exits non-zero if high/critical found)
  • Lock files committed (package-lock.json, poetry.lock, etc.)
    • Search: git ls-files | grep -E 'package-lock\.json|yarn\.lock|poetry\.lock|Pipfile\.lock|Gemfile\.lock'
  • Direct dependencies pinned to specific versions
    • Search: grep -E '"\^|"~|">=|">' package.json — each result is a non-pinned dependency

A07 - Authentication Failures

  • Session tokens invalidated on logout
    • Search: grep -rn 'logout\|signout\|sign_out' --include='*.js' --include='*.ts' --include='*.py' | grep -v 'destroy\|invalidate\|clear\|delete\|revoke'
  • Password reset tokens expire and are single-use
    • Search: grep -rn 'reset.*token\|token.*reset' --include='*.js' --include='*.ts' --include='*.py' — verify expiry and single-use enforcement
  • Brute force protection on login
    • Search: grep -rn 'login\|signin' --include='*.js' --include='*.ts' | grep -v 'attempts\|lockout\|rateLimit\|throttle'

A08 - Software and Data Integrity

  • Dependencies pinned to verified versions
  • No eval() or dynamic code execution with user input
    • Search: grep -rn 'eval(' --include='*.js' --include='*.ts' --include='*.py'
    • Also: grep -rn 'new Function(' --include='*.js' --include='*.ts'

A09 - Logging and Monitoring

  • Authentication events logged (success and failure)
    • Search: grep -rn 'login\|signin\|authenticate' --include='*.js' --include='*.ts' --include='*.py' | grep -v 'log\|audit\|event\|monitor'
  • Sensitive operations audited
  • Logs don't contain secrets or PII
    • Search: grep -rn 'log\.' --include='*.js' --include='*.ts' | grep -i 'password\|token\|secret\|ssn\|credit_card\|cvv'

Common Vulnerabilities to Check

VulnerabilityCheck
SQL InjectionAll queries parameterized?
XSSAll user content escaped before rendering?
CSRFState-changing requests have CSRF protection?
Path traversalFile paths sanitized and validated?
Secret exposureNo hardcoded keys/tokens in code?
Mass assignmentOnly allowed fields accepted from user input?

Red Flags in Code

These patterns require immediate review:

  • eval(), exec(), system() with any user-influenced input
  • String concatenation in SQL: "SELECT * FROM users WHERE id = " + userId
  • innerHTML = userContent (XSS)
  • require(userInput) or dynamic imports with user data
  • Secrets in .env files committed to git
  • MD5 or SHA1 for password hashing

Output

For each finding, document:

  1. Vulnerability type (OWASP category)
  2. Severity (Critical/High/Medium/Low)
  3. Location (file:line)
  4. Description (what's wrong and why)
  5. Fix (specific code change or pattern to use)

If no vulnerabilities found: output "Security Review: PASS. No issues found in [scope]. Reviewed: [list of OWASP categories checked]. Verified: [date and reviewer]."

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.