OWASP Top 10:2021 — Web Application Security Review

When to Use

If a target is provided via arguments, focus the review on: $ARGUMENTS

Invoke this skill when:

• Reviewing web application source code for security vulnerabilities.
• Auditing server or framework configurations (e.g., Express, Django, Rails, Spring Boot, ASP.NET).
• A user requests a "security review," "pentest prep," or "OWASP check" against a web application.
• Evaluating pull requests that touch authentication, authorization, input handling, cryptography, or external integrations.
• Assessing a new web project's architecture for secure design principles before implementation begins.

Do not use this skill for mobile-only, IoT firmware, or non-web API reviews — use a domain-specific skill instead.

Context

The OWASP Top 10:2021 is the authoritative awareness document for web application security. It represents broad consensus on the most critical security risks to web applications, derived from CWE data mapped across hundreds of organizations. Each category aggregates multiple CWEs under a unifying risk theme.

This skill operationalizes all ten categories into a repeatable, structured review process suitable for AI-assisted code analysis. Findings are mapped to specific CWEs, rated by severity, and paired with actionable remediation steps.

Process

Step 1 — Scope and Inventory

1. Use Glob to enumerate the project structure: source files, configuration files, dependency manifests, and infrastructure-as-code templates.
2. Identify the technology stack: language, framework, template engine, ORM, authentication library, and deployment target.
3. Catalog entry points: routes, controllers, API endpoints, middleware chains, and static asset serving.
4. Note dependency manifests (package.json, requirements.txt, pom.xml, Gemfile.lock, go.sum, etc.) for component analysis.

Step 2 — Category-by-Category Analysis

Evaluate the codebase against each of the ten categories below. For every category, search for the listed detection patterns using Grep and Read, then record findings.

Precision Requirements — Reducing False Positives:

Before including any finding in the report, apply the following verification gate:

1. Confirmed code path required. Only flag a vulnerability when you can identify the specific file path, line number, and the vulnerable code pattern. Do not report speculative or theoretical risks where no concrete vulnerable code exists.
2. Verify exploitability. For each potential finding, confirm that the vulnerable pattern is actually reachable and exploitable — not dead code, commented-out code, test fixtures, or intentionally disabled features with compensating controls elsewhere.
3. Distinguish "potential risk" from "confirmed vulnerability." A grep match on a detection pattern is not a finding by itself. Read the surrounding code context (at least 10-20 lines) to confirm the pattern represents an actual vulnerability. For example:
   • A Math.random() call used for UI animation is NOT a cryptographic failure.
   • An innerHTML assignment with a static string literal is NOT an XSS vulnerability.
   • A req.params.id used with proper ORM methods and authorization middleware is NOT an IDOR.
   • An exec() call on a hardcoded string with no user input is NOT command injection.
4. One finding per distinct vulnerability. Do not report multiple findings for the same underlying vulnerability pattern appearing in related code paths. Consolidate variants (e.g., two SQL injection points in the same query builder) into a single finding with multiple locations noted.
5. Match findings to ground-truth severity. Only report findings at severity levels proportional to actual exploitable impact. Infrastructure-level observations (missing headers, missing tooling, general architectural gaps) that lack a specific exploitable code path should be omitted or downgraded to Informational.

---

A01:2021 — Broken Access Control

Risk: Users act outside their intended permissions — accessing other users' data, elevating privileges, or bypassing access restrictions.

What to Look For:

• Missing or inconsistent authorization checks on endpoints and data-access functions.
• Direct object references (IDOR) where user-supplied IDs are used to fetch records without ownership validation.
• Endpoints that rely solely on client-side enforcement (hidden UI elements) rather than server-side checks.
• CORS misconfigurations that permit arbitrary origins or reflect the Origin header without validation.
• Missing HTTP method restrictions (e.g., a route that accepts PUT/DELETE but only intended for GET).
• JWT or session tokens that contain role claims without server-side verification against a trusted source.
• Path traversal in file-serving endpoints.
• Missing deny-by-default policies — routes are open unless explicitly restricted rather than closed unless explicitly opened.

CWE Mappings:

CWE	Name
CWE-200	Exposure of Sensitive Information to an Unauthorized Actor
CWE-201	Insertion of Sensitive Information Into Sent Data
CWE-352	Cross-Site Request Forgery (CSRF)
CWE-284	Improper Access Control
CWE-285	Improper Authorization
CWE-639	Authorization Bypass Through User-Controlled Key
CWE-862	Missing Authorization
CWE-863	Incorrect Authorization
CWE-22	Improper Limitation of a Pathname to a Restricted Directory (Path Traversal)

Detection Patterns (Grep):

# IDOR — direct use of user-supplied ID in DB query without ownership check
params\.id|req\.params|request\.args\.get.*id
# Missing CSRF protection
csrf.*disable|csrf.*false|@csrf_exempt
# Permissive CORS
Access-Control-Allow-Origin.*\*|cors\(\{.*origin.*true
# Path traversal indicators
\.\.\/|\.\.\\|path\.join.*req\.|sendFile.*req\.

Mitigations:

• Enforce authorization server-side on every request using middleware or decorators; adopt deny-by-default.
• Validate resource ownership — confirm the authenticated user owns or has explicit permission to the requested resource.
• Use indirect references or opaque tokens instead of sequential database IDs.
• Enable CSRF protection framework-wide; use SameSite cookie attributes.
• Restrict CORS to an explicit allowlist of origins; never reflect arbitrary Origin values.
• Constrain file paths with canonicalization and chroot/jail patterns; reject .. sequences.

---

A02:2021 — Cryptographic Failures

Risk: Sensitive data is exposed due to weak, missing, or misused cryptography — in transit, at rest, or during processing.

What to Look For:

• Plaintext storage of passwords, tokens, API keys, or PII.
• Use of deprecated algorithms: MD5, SHA-1 (for integrity of sensitive data), DES, 3DES, RC4, ECB mode.
• Hard-coded encryption keys or secrets in source code.
• Missing TLS enforcement — HTTP endpoints serving sensitive data, absent HSTS headers.
• Weak key derivation functions (e.g., raw SHA-256 for password hashing instead of bcrypt/scrypt/Argon2).
• Insufficient randomness — use of Math.random(), random.random(), or similar non-CSPRNG functions for security-sensitive values.
• Secrets committed to version control (.env files, config files with credentials).

CWE Mappings:

CWE	Name
CWE-259	Use of Hard-coded Password
CWE-261	Weak Encoding for Password
CWE-296	Improper Following of a Certificate's Chain of Trust
CWE-310	Cryptographic Issues
CWE-319	Cleartext Transmission of Sensitive Information
CWE-321	Use of Hard-coded Cryptographic Key
CWE-326	Inadequate Encryption Strength
CWE-327	Use of a Broken or Risky Cryptographic Algorithm
CWE-328	Use of Weak Hash
CWE-330	Use of Insufficiently Random Values
CWE-331	Insufficient Entropy
CWE-798	Use of Hard-coded Credentials

Detection Patterns (Grep):

# Weak hashing
md5|sha1|DES|RC4|ECB
# Hard-coded secrets
password\s*=\s*["']|secret\s*=\s*["']|api_key\s*=\s*["']|private_key\s*=\s*["']
# Insecure random
Math\.random|random\.random|rand\(\)
# Missing TLS
http:\/\/.*api|http:\/\/.*login|secure\s*:\s*false

Mitigations:

• Hash passwords exclusively with Argon2id, bcrypt (cost >= 10), or scrypt — never raw hash functions.
• Use AES-256-GCM or ChaCha20-Poly1305 for symmetric encryption; RSA-OAEP or ECDH for asymmetric.
• Store secrets in a vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) — never in source code or environment files committed to VCS.
• Enforce TLS 1.2+ for all connections; set Strict-Transport-Security with max-age >= 31536000; includeSubDomains.
• Use crypto.getRandomValues() (JS), secrets module (Python), or SecureRandom (Java/Ruby) for all security-sensitive random values.
• Classify data by sensitivity and apply encryption controls proportionally.

---

A03:2021 — Injection

Risk: Untrusted data is sent to an interpreter as part of a command or query, allowing attackers to execute unintended commands or access unauthorized data.

What to Look For:

• SQL queries built with string concatenation or template literals using user input.
• ORM calls that accept raw SQL fragments with unsanitized parameters.
• OS command execution with user-controlled arguments (exec, system, child_process.exec, os.system, subprocess.call with shell=True).
• LDAP queries built from user input without escaping.
• XPath/XML queries constructed with concatenation.
• Template injection — user input rendered directly into server-side templates (Jinja2, Thymeleaf, ERB, Twig).
• NoSQL injection via query operator injection ($gt, $ne, $regex in MongoDB).
• Header injection — user input placed into HTTP response headers without sanitization.

CWE Mappings:

CWE	Name
CWE-20	Improper Input Validation
CWE-74	Improper Neutralization of Special Elements in Output Used by a Downstream Component (Injection)
CWE-75	Failure to Sanitize Special Elements into a Different Plane
CWE-77	Improper Neutralization of Special Elements used in a Command (Command Injection)
CWE-78	Improper Neutralization of Special Elements used in an OS Command (OS Command Injection)
CWE-79	Improper Neutralization of Input During Web Page Generation (XSS)
CWE-80	Improper Neutralization of Script-Related HTML Tags
CWE-89	Improper Neutralization of Special Elements used in an SQL Command (SQL Injection)
CWE-90	Improper Neutralization of Special Elements used in an LDAP Query (LDAP Injection)
CWE-94	Improper Control of Generation of Code (Code Injection)
CWE-643	Improper Neutralization of Data within XPath Expressions (XPath Injection)
CWE-917	Improper Neutralization of Special Elements used in an Expression Language Statement (EL Injection)

Detection Patterns (Grep):

# SQL injection
execute\(.*%s|execute\(.*\+|query\(.*\+|\.raw\(|\.rawQuery\(|\$\{.*\}.*SELECT|\.format\(.*SELECT
# OS command injection
exec\(|system\(|popen\(|child_process|shell=True|Runtime\.getRuntime\(\)\.exec
# XSS / template injection
innerHTML|\.html\(|dangerouslySetInnerHTML|v-html|\|safe|\|raw|render_template_string
# NoSQL injection
\$where|\$gt|\$ne|\$regex.*req\.|find\(.*req\.
# Header injection
setHeader\(.*req\.|res\.set\(.*req\.|response\.addHeader.*request\.getParameter

Mitigations:

• Use parameterized queries (prepared statements) for all SQL — no exceptions.
• Use ORM methods properly; avoid raw query escape hatches unless inputs are strictly validated and parameterized.
• For OS commands, use array-based APIs (e.g., subprocess.run([...]) without shell=True); validate and allowlist expected argument values.
• Apply context-aware output encoding for XSS: HTML-encode for HTML body, attribute-encode for attributes, JS-encode for script contexts. Use frameworks' built-in auto-escaping.
• Validate and sanitize all input on the server side; use allowlists over denylists.
• Set Content-Security-Policy headers to mitigate XSS impact.

---

A04:2021 — Insecure Design

Risk: The application architecture lacks security controls by design — missing threat modeling, insecure business logic, absence of defense-in-depth.

What to Look For:

• Business logic that assumes client-side validation is sufficient (e.g., price set by client, quantity not validated server-side).
• Missing rate limiting on sensitive operations (login, password reset, OTP verification, account creation).
• No account lockout or progressive delays after repeated failed authentication attempts.
• Password reset flows that leak whether an account exists (different responses for valid vs. invalid emails).
• Multi-step workflows that can be completed out of order or with steps skipped.
• Missing trust boundaries — internal services accessible without authentication from external networks.
• Absence of security requirements or threat model documentation.

CWE Mappings:

CWE	Name
CWE-73	External Control of File Name or Path
CWE-183	Permissive List of Allowed Inputs
CWE-209	Generation of Error Message Containing Sensitive Information
CWE-256	Plaintext Storage of a Password
CWE-501	Trust Boundary Violation
CWE-522	Insufficiently Protected Credentials
CWE-602	Client-Side Enforcement of Server-Side Security
CWE-656	Reliance on Security Through Obscurity
CWE-799	Improper Control of Interaction Frequency
CWE-840	Business Logic Errors

Detection Patterns (Grep):

# Client-side-only validation
# (Look for validation logic only in frontend files, absent from backend handlers)
# Rate limiting absent
rateLimit|rate_limit|throttle|slowDown
# Account enumeration
"user not found"|"email not found"|"no account"|"invalid email"
# Missing lockout
failedAttempts|failed_attempts|lockout|max_attempts

Mitigations:

• Establish threat modeling early in the design phase (STRIDE, PASTA, or attack trees).
• Implement rate limiting and account lockout on all authentication and sensitive endpoints.
• Return generic error messages for authentication failures — never reveal whether a username or email exists.
• Enforce all business rules server-side; treat the client as untrusted.
• Define and enforce trust boundaries between components and network zones.
• Write abuse cases and negative test cases alongside functional requirements.
• Implement progressive security controls (defense-in-depth) so a single control failure does not compromise the system.

---

A05:2021 — Security Misconfiguration

Risk: The application or its infrastructure is insecure due to missing hardening, default settings, open cloud storage, verbose error messages, or unnecessary features enabled.

What to Look For:

• Default credentials left in place (admin/admin, root/root, default API keys).
• Debug mode enabled in production (DEBUG=True, NODE_ENV=development, stack traces returned to users).
• Unnecessary HTTP methods enabled (TRACE, OPTIONS returning sensitive data).
• Directory listing enabled on web servers.
• Default or sample pages/applications deployed to production.
• Missing or misconfigured security headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy).
• Cloud storage buckets with public access (S3, GCS, Azure Blob).
• XML parsers configured to allow external entities (XXE).
• Verbose error pages that expose stack traces, framework versions, or internal paths.

CWE Mappings:

CWE	Name
CWE-2	Direct Use of Environment Configuration File
CWE-11	ASP.NET Misconfiguration: Creating Debug Binary
CWE-13	ASP.NET Misconfiguration: Password in Configuration File
CWE-15	External Control of System or Configuration Setting
CWE-16	Configuration
CWE-611	Improper Restriction of XML External Entity Reference (XXE)
CWE-614	Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
CWE-756	Missing Custom Error Page
CWE-776	Improper Restriction of Recursive Entity References in DTDs (XML Entity Expansion)
CWE-942	Permissive Cross-domain Policy with Untrusted Domains

Detection Patterns (Grep):

# Debug mode
DEBUG\s*=\s*True|debug\s*:\s*true|NODE_ENV.*development
# XXE
DocumentBuilderFactory|SAXParser|XMLReader|etree\.parse|lxml.*parse
# Missing security headers
X-Content-Type-Options|X-Frame-Options|Content-Security-Policy|Strict-Transport-Security
# Default credentials
admin.*admin|password.*password|default.*key|changeme|TODO.*password
# Verbose errors
stack.*trace|stackTrace|detailed.*error|showErrors\s*:\s*true

Mitigations:

• Automate environment hardening with configuration management (Ansible, Terraform, Helm) and enforce it in CI/CD.
• Remove all default credentials, sample applications, and unused features before deployment.
• Set DEBUG=False / NODE_ENV=production in all production configurations.
• Disable XML external entity processing in all XML parsers by default.
• Deploy security headers via middleware or reverse proxy — audit with tools like securityheaders.com.
• Configure custom error pages that reveal no internal details; log full errors server-side only.
• Run periodic configuration audits (CIS Benchmarks, cloud provider security tools).

---

A06:2021 — Vulnerable and Outdated Components

Risk: The application uses libraries, frameworks, or other software components with known vulnerabilities, or components that are no longer maintained.

What to Look For:

• Dependency manifests with pinned versions that have known CVEs.
• Lack of a lock file (package-lock.json, Pipfile.lock, Gemfile.lock, go.sum) leading to non-reproducible builds.
• Dependencies pulled from untrusted or unverified registries.
• Use of deprecated or end-of-life frameworks or runtime versions (e.g., Python 2, Node.js LTS-expired versions, Angular.js).
• No automated dependency scanning in CI/CD pipeline.
• Vendored or copy-pasted library code that will never receive upstream patches.

CWE Mappings:

CWE	Name
CWE-829	Inclusion of Functionality from Untrusted Control Sphere
CWE-1035	OWASP Top Ten 2017 Category A9 — Using Components with Known Vulnerabilities
CWE-1104	Use of Unmaintained Third-Party Components

Detection Patterns (Grep):

# Dependency files to inspect
package\.json|requirements\.txt|Pipfile|Gemfile|pom\.xml|build\.gradle|go\.mod|composer\.json
# Lock files (verify existence)
package-lock\.json|yarn\.lock|Pipfile\.lock|Gemfile\.lock|composer\.lock
# Deprecated libraries (examples)
angular\.js|jquery\s*["\'].*1\.|lodash.*3\.|moment\(\)|request\(  # (npm 'request' is deprecated)

Mitigations:

• Integrate automated dependency scanning (Dependabot, Snyk, Trivy, OWASP Dependency-Check) into CI/CD.
• Maintain lock files and review dependency updates regularly.
• Subscribe to security advisories for all direct dependencies.
• Remove unused dependencies; prefer well-maintained libraries with active security response processes.
• Establish a policy for maximum time-to-patch for critical and high CVEs (e.g., critical within 48 hours).
• Use Software Composition Analysis (SCA) tools to generate and monitor SBOMs.

---

A07:2021 — Identification and Authentication Failures

Risk: Authentication mechanisms are weak, broken, or missing, allowing attackers to compromise passwords, keys, or session tokens, or to exploit implementation flaws to assume other users' identities.

What to Look For:

• No protection against credential stuffing or brute-force attacks (missing rate limiting on login).
• Weak password policies (no minimum length, no complexity requirements, no check against breached password lists).
• Credentials transmitted over unencrypted connections.
• Session tokens in URLs (logged in proxies, referer headers, browser history).
• Session IDs that do not rotate after successful authentication.
• Missing multi-factor authentication on privileged accounts.
• "Remember me" tokens that never expire or use predictable values.
• Password recovery that uses knowledge-based questions or sends passwords in plaintext.

CWE Mappings:

CWE	Name
CWE-255	Credentials Management Errors
CWE-287	Improper Authentication
CWE-288	Authentication Bypass Using an Alternate Path or Channel
CWE-290	Authentication Bypass by Spoofing
CWE-294	Authentication Bypass by Capture-replay
CWE-295	Improper Certificate Validation
CWE-297	Improper Validation of Certificate with Host Mismatch
CWE-300	Channel Accessible by Non-Endpoint
CWE-302	Authentication Bypass by Assumed-Immutable Data
CWE-304	Missing Critical Step in Authentication
CWE-306	Missing Authentication for Critical Function
CWE-307	Improper Restriction of Excessive Authentication Attempts
CWE-384	Session Fixation
CWE-521	Weak Password Requirements
CWE-613	Insufficient Session Expiration

Detection Patterns (Grep):

# Session management
session\.id|sessionId|JSESSIONID|connect\.sid|session_token
# Weak password policy
minLength.*[0-5]|passwordMinLength|min_password_length
# Session in URL
session.*=.*req\.query|token.*=.*req\.query|url.*session
# Missing session rotation
regenerate|rotateSession|session\.create|session_regenerate_id
# Certificate validation bypass
rejectUnauthorized\s*:\s*false|verify\s*=\s*False|CERT_NONE|InsecureRequestWarning.*disable

Mitigations:

• Implement rate limiting and account lockout on authentication endpoints.
• Enforce minimum password length of 12 characters (NIST 800-63B requires at least 8; OWASP ASVS V2.1.1 recommends at least 12); verifiers SHOULD permit at least 64; check passwords against breached-password databases (e.g., HaveIBeenPwned API).
• Regenerate session IDs after login, privilege escalation, and re-authentication.
• Set session cookies with Secure, HttpOnly, and SameSite=Lax (or Strict) attributes.
• Implement multi-factor authentication for all users, mandatory for administrative accounts.
• Set absolute and idle session timeouts appropriate to the application's risk profile.
• Never expose session tokens in URLs.

---

A08:2021 — Software and Data Integrity Failures

Risk: Code and infrastructure lack integrity verification, allowing attackers to introduce malicious updates, tamper with CI/CD pipelines, or exploit insecure deserialization.

What to Look For:

• Deserialization of untrusted data (Java ObjectInputStream, Python pickle/yaml.load, PHP unserialize, Ruby Marshal.load, .NET BinaryFormatter).
• Software updates delivered without digital signature verification.
• CI/CD pipelines that pull dependencies or scripts from unverified sources.
• Missing Subresource Integrity (SRI) hashes on CDN-hosted scripts and stylesheets.
• Auto-update mechanisms that do not verify package signatures or checksums.
• Unsigned or unverified webhook payloads triggering automated actions.

CWE Mappings:

CWE	Name
CWE-345	Insufficient Verification of Data Authenticity
CWE-353	Missing Support for Integrity Check
CWE-426	Untrusted Search Path
CWE-494	Download of Code Without Integrity Check
CWE-502	Deserialization of Untrusted Data
CWE-565	Reliance on Cookies without Validation and Integrity Checking
CWE-784	Reliance on Cookies without Validation and Integrity Checking in a Security Decision
CWE-829	Inclusion of Functionality from Untrusted Control Sphere

Detection Patterns (Grep):