/owasp-security

name: owasp-security
description: Use when reviewing code for security vulnerabilities, implementing authentication/authorization, handling user input, or discussing web application security. Covers OWASP Top 10:2025, ASVS 5.0, LLM Top 10 (2025), and Agentic AI security (2026).

OWASP Security Best Practices Skill

Apply these security standards when writing or reviewing code.

**Reference files** (load on demand):

• [`reference/languages.md`](reference/languages.md) — per-language security quirks with unsafe/safe examples for 20+ languages.
• [`reference/owasp-report.md`](reference/owasp-report.md) — comprehensive deep-dive on every OWASP 2025–2026 standard.

Quick Reference: OWASP Top 10:2025

| # | Vulnerability | Key Prevention | |---|---------------|----------------| | A01 | Broken Access Control | Deny by default, enforce server-side, verify ownership | | A02 | Security Misconfiguration | Harden configs, disable defaults, minimize features | | A03 | Software Supply Chain Failures | Lock versions, verify integrity, audit dependencies | | A04 | Cryptographic Failures | TLS 1.2+, AES-256-GCM, Argon2/bcrypt for passwords | | A05 | Injection | Parameterized queries, input validation, safe APIs | | A06 | Insecure Design | Threat model, rate limit, design security controls | | A07 | Authentication Failures | MFA, check breached passwords, secure sessions | | A08 | Software or Data Integrity Failures | Sign packages, SRI for CDN, safe serialization | | A09 | Security Logging and Alerting Failures | Log security events, structured format, alerting | | A10 | Mishandling of Exceptional Conditions | Fail-closed, hide internals, log with context |

Before Reporting a Finding

A pattern match is not a vulnerability. The most common failure mode in automated security review is reporting unreachable or already-mitigated code, which buries the real findings. Confirm all three before reporting:

1. **Is the input actually attacker-controlled?** Trace it back to a real entry point — a request parameter, header, cookie, uploaded file, webhook, queue message, or third-party API response. A value that only ever comes from a constant, an enum, or trusted internal config is not an injection source. 2. **Is the sink reachable with that input?** Check whether validation, an allowlist, an ORM, or a framework-level control already sits between them. Look for auth middleware (`middleware.ts`, `proxy.ts`, Express/Django/Rails middleware, a base controller, decorators) before flagging a route as missing authorization — enforcement is often centralized rather than per-route. 3. **What is the blast radius?** Who can trigger it, what do they get, and does it cross a trust boundary? An SSRF reaching cloud metadata differs from one reaching localhost only.

Report severity by exploitability, not by pattern. State the concrete path — *this input reaches this sink* — and say so explicitly when a finding is theoretical or defense-in-depth rather than directly exploitable. If reachability can't be determined from the code available, say that instead of asserting either way.

Security Code Review Checklist

When reviewing code, check for these issues:

Input Handling

• [ ] All user input validated server-side
• [ ] Using parameterized queries (not string concatenation)
• [ ] Input length limits enforced
• [ ] Allowlist validation preferred over denylist

Authentication & Sessions

• [ ] Passwords hashed with Argon2/bcrypt (not MD5/SHA1)
• [ ] Session tokens have sufficient entropy (128+ bits)
• [ ] Sessions invalidated on logout
• [ ] MFA available for sensitive operations

Access Control

• [ ] Authorization checked on every request
• [ ] Using object references user cannot manipulate
• [ ] Deny by default policy
• [ ] Privilege escalation paths reviewed

Data Protection

• [ ] Sensitive data encrypted at rest
• [ ] TLS for all data in transit
• [ ] No sensitive data in URLs/logs
• [ ] Secrets in environment/vault (not code)

Error Handling

• [ ] No stack traces exposed to users
• [ ] Fail-closed on errors (deny, not allow)
• [ ] All exceptions logged with context
• [ ] Consistent error responses (no enumeration)

Secure Code Patterns

SQL Injection Prevention

# UNSAFE
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

# SAFE
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

Command Injection Prevention

# UNSAFE
os.system(f"convert {filename} output.png")

# SAFE
subprocess.run(["convert", filename, "output.png"], shell=False)

Password Storage

# UNSAFE
hashlib.md5(password.encode()).hexdigest()

# SAFE
from argon2 import PasswordHasher
PasswordHasher().hash(password)

Access Control

# UNSAFE - No authorization check
@app.route('/api/user/<user_id>')
def get_user(user_id):
    return db.get_user(user_id)

# SAFE - Authorization enforced
@app.route('/api/user/<user_id>')
@login_required
def get_user(user_id):
    if current_user.id != user_id and not current_user.is_admin:
        abort(403)
    return db.get_user(user_id)

Error Handling

# UNSAFE - Exposes internals
@app.errorhandler(Exception)
def handle_error(e):
    return str(e), 500

# SAFE - Fail-closed, log context
@app.errorhandler(Exception)
def handle_error(e):
    error_id = uuid.uuid4()
    logger.exception(f"Error {error_id}: {e}")
    return {"error": "An error occurred", "id": str(error_id)}, 500

Fail-Closed Pattern

# UNSAFE - Fail-open
def check_permission(user, resource):
    try:
        return auth_service.check(user, resource)
    except Exception:
        return True  # DANGEROUS!

# SAFE - Fail-closed
def check_permission(user, resource):
    try:
        return auth_service.check(user, resource)
    except Exception as e:
        logger.error(f"Auth check failed: {e}")
        return False  # Deny on error

Agentic AI Security (OWASP 2026)

When buildi