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 Command Injection Prevention Password Storage Access Control Error Handling Fail Closed Pattern Agentic AI Security (OWASP 2026) When building or reviewing AI agent systems, check for: Risk Description Mitigation ASI01: Agent Goal Hijacking Prompt injection alters agent objectives Input sanitization, goal boundaries, behavioral monitoring ASI02: Tool Misuse Tools used in unintended ways Least privilege, fine grained permissions, validate I/O ASI03: Identity & Privilege Abuse Delegated trust, inherited credentials, role chain exploits Short lived scoped tokens, identity verification ASI04: Agentic Supply Chain Vulnerabilities Compromised plugins/MCP servers Verify signatures, sandbox, allowlist plugins ASI05: Unexpected Code Execution Unsafe code generation/execution Sandbox execution, static analysis, human approval ASI06: Memory & Context Poisoning Corrupted RAG/context data Validate stored content, segment by trust level ASI07: Insecure Inter Agent Comms Spoofing/intercepting agent to agent messages Authenticate, encrypt, verify message integrity ASI08: Cascading Failures Errors propagate across systems Circuit breakers, graceful degradation, isolation ASI09: Human Agent Trust Exploitation Over trust in agents leveraged to manipulate users Label AI content, user education, verification steps ASI10: Rogue Agents Compromised agents acting maliciously Behavior monitoring, kill switches, anomaly detection OWASP Top 10 for LLM Applications (2025) When building or reviewing applications that call LLMs (chatbots, RAG, copilots, agents), check for: Risk Key Mitigation LLM01 Prompt Injection Separate trusted instructions from untrusted data, filter outputs, isolate privileges between user/tool/system context LLM02 Sensitive Information Disclosure Sanitize training/RAG data, strip PII from context, restrict what the model can retrieve per user LLM03 Supply Chain Verify model provenance and signatures, vet third party model hubs, lock model + adapter versions LLM04 Data and Model Poisoning Validate training/fine tuning sources, anomaly detect on data ingestion, hold out integrity tests LLM05 Improper Output Handling Treat all LLM output as untrusted input — validate, escape, or sandbox before passing downstream (SQL, shell, HTML, code, tool calls) LLM06 Excessive Agency Minimize tools and permissions, require human approval for destructive actions, scope credentials per task LLM07 System Prompt Leakage Never put secrets, keys, or auth logic in the system prompt; assume the prompt is extractable LLM08 Vector and Embedding Weaknesses Tenant isolate vector stores, access control on retrieval, sign or hash chunks against indirect prompt injection LLM09 Misinformation Cite sources, surface confidence, require grounding for high stakes answers, disclose AI provenance LLM10 Unbounded Consumption Rate limit per user/key, cap tokens and tool calls per request, monitor cost, set hard timeouts Prompt Injection Prevention (LLM01) Improper Output Handling (LLM05) Worked examples for Excessive Agency (LLM06) and Unbounded Consumption (LLM10), plus attack vectors for all ten risks, are in [ reference/owasp report.md ](reference/owasp report.md). ASVS 5.0 Key Requirements ASVS 5.0 (May 2025) renumbered and reorganized every chapter. 4.0 requirement IDs do not map to 5.0 — V2.1.1 meant "password length" in 4.0 and means something else now. Cite 5.0 IDs only. Levels are defined by share of requirements, not by application category: Level Share Intent L1 ~20% Minimum bar; deliberately small to lower the barrier to entry L2 ~50% (≈70% cumulative) What most applications should target L3 remaining ~30% Highest assurance Level 1 — the minimum bar Passwords at least 8 characters ; 15+ strongly recommended (6.2.1) No composition rules — permit any characters, paste, and password managers (6.2.5, 6.2.7) Block at least the top 3000 common passwords (6.2.4) Anti automation against credential stuffing and brute force (6.3.1) No default accounts like root / admin / sa (6.3.2) Reference session tokens from a CSPRNG with 128+ bits entropy (7.2.3) New session token issued on authentication and re authentication (7.2.4) Session fully unusable after logout or expiry (7.4.1) Function level and data level access restricted to explicit permissions (8.2.1, 8.2.2) Authorization enforced at a trusted service layer the client cannot manipulate (8.3.1) Parameterized queries / ORM for all data access (1.2.4); parameterized OS calls (1.2.5) Context appropriate output encoding for HTML, URLs, and JavaScript/JSON (1.2.1–1.2.3) Avoid eval() and dynamic code execution (1.3.2) Input validated at a trusted service layer, positive/allowlist where possible (2.2.1, 2.2.2) TLS 1.2+ on all external traffic, publicly trusted certificates (12.1.1, 12.2.1, 12.2.2) Approved ciphers and modes only — no ECB, no PKCS 1 v1.5 padding (11.3.1, 11.3.2) No sensitive data in URLs or query strings (14.2.1) Level 2 — what most applications should target MFA, or a documented combination of single factors (6.3.3) Passwords checked against a breached password set (6.2.12) No forced periodic password rotation — rotate only on compromise (6.2.10) All security logging starts here. ASVS 5.0 has no L1 logging requirements; the whole of V16 is L2+. Log authentication attempts, failed authorization, security events, and unexpected errors (16.3.1–16.3.4) Log entries carry when/where/who/what metadata on a synchronized clock (16.2.1, 16.2.2) Logs encoded against log injection, protected from modification, shipped off box (16.4.1–16.4.3) Generic error message to the user; detail stays in the log (16.5.1) Level 3 — highest assurance ASVS 5.0 has 92 L3 requirements ; they are not enumerated here. Two worth knowing because they tighten an L2 requirement rather than adding a new one: One factor must be hardware based and phishing resistant, e.g. a FIDO key (6.3.3, L3 clause) Log all authorization decisions, not only failures (16.3.2, L3 clause) For an actual L3 assessment, work from the standard itself — see [ reference/owasp report.md ](reference/owasp report.md) for the chapter map. Language Specific Security Quirks For per language unsafe/safe examples and the functions to watch for across 20+ languages, see [ reference/languages.md ](reference/languages.md). For anything not covered there, apply the mindset below. Deep Security Analysis Mindset When reviewing any language, think like a senior security researcher: 1. Memory Model: How does the language handle memory? Managed vs manual? GC pauses exploitable? 2. Type System: Weak typing = type confusion attacks. Look for coercion exploits. 3. Serialization: Every language has its pickle/Marshal equivalent. All are dangerous. 4. Concurrency: Race conditions, TOCTOU, atomicity failures specific to the threading model. 5. FFI Boundaries: Native interop is where type safety breaks down. 6. Standard Library: Historic CVEs in std libs (Python urllib, Java XML, Ruby OpenSSL). 7. Package Ecosystem: Typosquatting, dependency confusion, malicious packages. 8. Build System: Makefile/gradle/npm script injection during builds. 9. Runtime Behavior: Debug vs release differences (Rust overflow, C++ assertions). 10. Error Handling: How does the language fail? Silently? With stack traces? Fail open? These are entry points, not complete coverage — research the language's own CWE patterns, CVE history, and known footguns.

owasp-security