CWE
debt(d5/e3/b3/t5)
Closest to 'specialist tool catches' (d5). The term's detection_hints.tools lists semgrep, checkmarx, and sonarqube — these are specialist SAST tools that can flag security fixes without documented CWE references or missing vulnerability taxonomy. Not caught by default linters, but automated tooling can detect the absence of CWE classification in security-related code changes.
Closest to 'simple parameterised fix' (e3). The quick_fix indicates adding CWE IDs to code comments and bug trackers — this is slightly more than a one-line patch since it requires identifying the correct CWE classification and updating documentation/tracking systems, but it's a straightforward pattern application within a single component or ticket.
Closest to 'localised tax' (b3). CWE is a classification standard that applies to web and cli contexts per applies_to. The burden falls primarily on security documentation and vulnerability management workflows — it's not load-bearing across the entire codebase architecture, but teams that don't adopt consistent CWE usage pay a localized tax in vulnerability communication and tooling integration.
Closest to 'notable trap' (t5). The misconception field explicitly states that developers confuse CWE (weakness class) with CVE (specific vulnerability instance). Common_mistakes reinforce this: using generic CWE-20 instead of specific child CWEs, and confusing CWE with CVE. This is a documented gotcha that most security-aware developers eventually learn, but the distinction is not obvious from the names alone.
Also Known As
TL;DR
Explanation
CWE is maintained by MITRE and provides a standardised taxonomy of software and hardware weaknesses. Each weakness has a unique identifier (e.g. CWE-89 for SQL Injection) with a detailed description, extended description, demonstrative examples, and mitigations. CWEs describe the type of weakness, while CVEs describe specific vulnerability instances in real software. PHP Clarity Lab maps each detected issue to its CWE for precise classification.
Common Misconception
Why It Matters
Common Mistakes
- Mapping all injection vulnerabilities to the generic CWE-20 (Improper Input Validation) instead of specific child CWEs like CWE-89 (SQL) or CWE-79 (XSS).
- Not including CWE IDs in vulnerability reports, making historical trending and tooling correlation impossible.
- Confusing CWE (weakness type classification) with CVE (specific vulnerability instance).
- Using top-level abstract CWEs that do not map to actionable fixes — use the most specific applicable CWE.
Code Examples
// Vulnerability report with no CWE — no actionable classification:
[
'title' => 'User input not sanitised',
'severity' => 'High',
// Missing: 'cwe' => 'CWE-89', 'owasp' => 'A03:2021'
]# Common Weakness Enumeration — key CWEs for PHP apps
# CWE-89 SQL Injection — use prepared statements
# CWE-79 XSS — htmlspecialchars() on output
# CWE-22 Path Traversal — realpath() + prefix check
# CWE-78 OS Command Injection — escapeshellarg() or proc_open array
# CWE-352 CSRF — CSRF token + SameSite cookie
# CWE-434 Unrestricted Upload — finfo MIME check + random filename
# CWE-502 Insecure Deserialise— use JSON, not unserialize()
# CWE-798 Hard-coded Creds — use environment variables
# CWE-611 XXE — LIBXML_NONET | LIBXML_NOENT
# CWE-918 SSRF — allowlist outbound URLs
// Reference in docblocks:
/** @security CWE-89 — parameterised query, no string concat */
function findUser(int \$id): ?array {
\$stmt = \$pdo->prepare('SELECT * FROM users WHERE id = ?');
\$stmt->execute([\$id]);
return \$stmt->fetch() ?: null;
}