Owasp Top 10 Web

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.

1. 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.
2. 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 Restrict

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: UnitOneAI
• Source: UnitOneAI/SecuritySkills
• License: MIT
• Homepage: https://www.unitone.ai

Install and usage instructions live in the source repository linked above.