OWASP Top 10, CWE and SANS Top 25

1. Why This Topic Matters

Secure software implementation is where design intentions meet real code, and it is where most exploitable defects are born. The CSSLP exam (Domain 4: Secure Software Implementation) expects you to recognise the most common and most dangerous classes of coding weaknesses, know how they are catalogued, and know how to prevent, detect and remediate them. The three industry references that anchor this knowledge are:

• OWASP Top 10 - the most widely cited awareness list of critical web application security risks.
• CWE (Common Weakness Enumeration) - the master dictionary of software and hardware weakness types maintained by MITRE.
• SANS Top 25 / CWE Top 25 - a prioritised list of the most dangerous software weaknesses, originally produced by SANS and MITRE, now published annually by MITRE with CISA support.

Why do these matter to a security professional? Because they turn an infinite problem ('write secure code') into a finite, prioritised checklist. They give developers, testers, auditors and vendors a common language (e.g. 'this is CWE-89'), they feed into coding standards, static analysis rule sets, security requirements, penetration testing scopes and procurement contracts, and they are explicitly referenced by PCI DSS, NIST, ISO 27034, and many regulatory frameworks. For the exam, they are also a favourite source of scenario questions: 'A tester finds X - which category/weakness/mitigation applies?'

2. What They Are - Definitions and Ownership

OWASP (Open Worldwide Application Security Project) is a non-profit, vendor-neutral community. Its Top 10 is an awareness document (not a standard or a complete checklist) listing the ten most critical risk categories for web applications. It is updated roughly every three to four years based on data contributed by organisations plus a community survey. Each entry is a risk category that groups many individual CWEs.

CWE (Common Weakness Enumeration) is a community-developed, formal list of software and hardware weakness types maintained by MITRE and sponsored by the US Department of Homeland Security / CISA. Each weakness has a unique identifier (e.g. CWE-79 Cross-Site Scripting). CWE describes types of mistakes, not specific vulnerabilities in specific products. It is hierarchical: Pillars, Classes, Bases and Variants, with Views (e.g. Research View, Development View, Architectural View) that organise weaknesses for different audiences.

SANS Top 25 / CWE Top 25 Most Dangerous Software Weaknesses was first published in 2009 as a joint effort of the SANS Institute and MITRE with input from many security experts. It originally grouped weaknesses into three categories: Insecure Interaction Between Components, Risky Resource Management, and Porous Defenses. Since 2019 MITRE has produced the list annually using a data-driven method: it maps CVEs in the NIST National Vulnerability Database to CWEs and scores each CWE by frequency and average CVSS severity. The exam may call it either 'SANS Top 25' or 'CWE Top 25'; treat them as the same lineage.

Key distinction you must know:
• CWE = a weakness type (the kind of mistake, e.g. SQL injection).
• CVE (Common Vulnerabilities and Exposures) = a specific instance of a vulnerability in a specific product/version (e.g. CVE-2021-44228 Log4Shell).
• CAPEC (Common Attack Pattern Enumeration and Classification) = attack patterns an adversary uses to exploit weaknesses.
• CVSS = a scoring system for the severity of a vulnerability.
• CWSS / CWRAF = Common Weakness Scoring System and Common Weakness Risk Analysis Framework, used to prioritise CWEs for a particular business context.
• OWASP Top 10 = a risk category list for web apps, each category mapping to multiple CWEs.

3. The OWASP Top 10 (2021 Edition) in Detail

A01: Broken Access Control - Users act outside their intended permissions: IDOR (insecure direct object reference), path traversal, privilege elevation, missing function-level checks, CORS misconfiguration. Mitigation: deny by default, enforce access control server-side on every request, use centralised authorisation, test with multiple roles. Related CWEs: 22, 284, 285, 352, 639, 862, 863.

A02: Cryptographic Failures (formerly Sensitive Data Exposure) - Weak or missing encryption, hard-coded keys, deprecated algorithms (MD5, SHA-1, DES, RC4), poor randomness, data in transit without TLS. Mitigation: classify data, encrypt in transit and at rest, use vetted libraries and strong algorithms (AES-256, SHA-256+, bcrypt/Argon2 for passwords), proper key management. Related CWEs: 259, 327, 328, 331.

A03: Injection - Untrusted data sent to an interpreter as part of a command or query: SQL, NoSQL, OS command, LDAP, XPath, and (now merged here) Cross-Site Scripting. Mitigation: parameterised queries/prepared statements, stored procedures done safely, input validation (allow-list), output encoding, least privilege for DB accounts, ORMs. Related CWEs: 20, 74, 77, 78, 79, 89, 94.

A04: Insecure Design (new in 2021) - Missing or ineffective security controls at the design level; cannot be fixed by perfect implementation. Mitigation: threat modelling, secure design patterns, reference architectures, abuse/misuse cases, security requirements. Related CWEs: 209, 256, 501, 522.

A05: Security Misconfiguration - Default accounts, verbose error messages, unnecessary features enabled, missing hardening, XML External Entities (XXE) is now included here. Mitigation: hardened repeatable build process, minimal platform, remove defaults, automated configuration verification, disable DTDs/external entities in XML parsers. Related CWEs: 16, 611.

A06: Vulnerable and Outdated Components - Using libraries, frameworks and runtimes with known vulnerabilities or no longer supported. Mitigation: software composition analysis (SCA), SBOM, inventory, patch management, remove unused dependencies, only use trusted sources. Related CWEs: 1104.

A07: Identification and Authentication Failures - Credential stuffing, brute force, weak passwords, poor session management, missing MFA. Mitigation: MFA, no default credentials, password strength checks against breached lists, rate limiting, secure session IDs regenerated after login, server-side session invalidation. Related CWEs: 287, 297, 384.

A08: Software and Data Integrity Failures (new) - Code and infrastructure that do not protect against integrity violations: insecure deserialisation, unsigned updates, compromised CI/CD pipelines, untrusted CDNs. Mitigation: digital signatures, verify integrity of packages, secure CI/CD, do not deserialise untrusted data, Subresource Integrity. Related CWEs: 345, 353, 426, 494, 502, 829.

A09: Security Logging and Monitoring Failures - Insufficient logging, unclear logs, no alerting, logs not protected. Mitigation: log all auth/access-control/validation failures with enough context, centralise and protect logs, establish monitoring and incident response. Related CWEs: 117, 223, 532, 778.

A10: Server-Side Request Forgery (SSRF) (new) - Application fetches a remote resource using a user-supplied URL without validation, letting attackers reach internal systems or cloud metadata services. Mitigation: allow-list destinations, network segmentation, disable redirects, do not return raw responses. Related CWE: 918.

Changes from 2017 you may be tested on: Injection fell from #1 to #3; Broken Access Control rose to #1; XSS merged into Injection; XXE merged into Misconfiguration; Insecure Deserialisation merged into Software and Data Integrity Failures; three new categories (Insecure Design, Software and Data Integrity Failures, SSRF). Note also that OWASP publishes other lists: the OWASP Mobile Top 10, OWASP API Security Top 10, OWASP Top 10 for LLM Applications, and the proactive-control companion OWASP Top 10 Proactive Controls, plus the OWASP ASVS (Application Security Verification Standard) which is a true standard rather than an awareness list.

4. The CWE Top 25 - Key Entries and Classic SANS Categories

The exact ranking changes yearly, but a stable core of weaknesses appears every year and these are the ones to know with their CWE IDs:

• CWE-787 Out-of-bounds Write and CWE-125 Out-of-bounds Read - buffer overflow family; mitigated by memory-safe languages, bounds checking, safe string functions, ASLR/DEP/stack canaries.
• CWE-79 Cross-Site Scripting - output encoding, Content Security Policy, HttpOnly cookies.
• CWE-89 SQL Injection - parameterised queries.
• CWE-78 OS Command Injection and CWE-77 Command Injection - avoid shell calls, allow-list validation.
• CWE-20 Improper Input Validation - validate on the server, allow-list, canonicalise before validating.
• CWE-416 Use After Free and CWE-476 NULL Pointer Dereference - memory management defects.
• CWE-22 Path Traversal - canonicalise paths, restrict to a base directory.
• CWE-352 Cross-Site Request Forgery - anti-CSRF tokens, SameSite cookies.
• CWE-434 Unrestricted Upload of File with Dangerous Type - validate type and content, store outside web root.
• CWE-862 Missing Authorization and CWE-863 Incorrect Authorization - access control defects.
• CWE-287 Improper Authentication and CWE-306 Missing Authentication for Critical Function.
• CWE-190 Integer Overflow or Wraparound - range checks, safe integer libraries.
• CWE-502 Deserialization of Untrusted Data.
• CWE-798 Use of Hard-coded Credentials - secrets vaults, never embed in code.
• CWE-918 Server-Side Request Forgery.
• CWE-362 Race Condition (TOCTOU) - atomic operations, locking.
• CWE-269 Improper Privilege Management and CWE-276 Incorrect Default Permissions.
• CWE-94 Improper Control of Generation of Code (Code Injection).
• CWE-119 Improper Restriction of Operations within Memory Buffer.
• CWE-400 Uncontrolled Resource Consumption - denial of service.

The three original SANS Top 25 categories are still a useful mental model and still appear in CSSLP material:
1. Insecure Interaction Between Components - how data is sent and received between modules, programs, processes or systems: SQL injection, OS command injection, XSS, CSRF, unrestricted file upload, open redirect.
2. Risky Resource Management - improper creation, use, transfer or destruction of resources: buffer overflows, path traversal, downloading code without integrity check, use of potentially dangerous functions, integer overflow, uncontrolled format string.
3. Porous Defenses - defensive techniques that are missing, misused or abused: missing authentication, missing authorisation, hard-coded credentials, missing encryption, broken/risky crypto, incorrect permissions, reliance on untrusted inputs in a security decision, excessive privileges.

5. How They Work Together in the SDLC

• Requirements: Use OWASP ASVS and the Top 10 to derive security requirements; use CWE IDs to make requirements testable ('the application shall be free of CWE-89').
• Design: Threat modelling (STRIDE) maps threats to CWE weaknesses and CAPEC attack patterns; OWASP A04 Insecure Design is addressed here.
• Implementation: Secure coding standards (CERT, OWASP Cheat Sheets) are organised by CWE; developers get IDE plug-ins and SAST tools whose rules are tagged with CWE IDs; peer code review checklists are built from the Top 25.
• Testing: SAST, DAST, IAST and SCA tools report findings by CWE; penetration test scopes often say 'cover the OWASP Top 10'; CVSS/CWSS prioritise remediation.
• Deployment and Operations: Vulnerability management uses CVE (instances) linked back to CWE (root cause) so the organisation can fix the class of bug, not just one occurrence. Metrics such as 'defects per CWE category' show whether training is working.
• Supply Chain and Acquisition: Contracts may require vendors to attest that software is free of the CWE/SANS Top 25 (the original SANS list came with sample procurement language for exactly this purpose).

6. Fundamental Mitigation Principles Behind All Three Lists

Almost every entry collapses to a handful of secure implementation practices the CSSLP expects you to cite:
• Input validation - allow-list (whitelist) over deny-list; validate type, length, range, format; validate on the server; canonicalise first.
• Output encoding - context-appropriate (HTML, attribute, JavaScript, URL, SQL).
• Parameterised interfaces - prepared statements, safe APIs instead of string concatenation.
• Least privilege - for processes, database accounts, file permissions, and users.
• Defense in depth - multiple overlapping controls, fail securely.
• Complete mediation - check authorisation on every access.
• Secure defaults and hardening - remove samples, disable unneeded features.
• Do not trust the client - all security decisions server-side.
• Use proven cryptography and libraries - never roll your own.
• Memory safety - bounds checks, safe functions, compiler protections, memory-safe languages where feasible.
• Error handling and logging - generic messages to users, detailed secure logs for administrators.
• Integrity verification - signed code, signed updates, verified dependencies.

7. Exam Tips: Answering Questions on OWASP Top 10, CWE and SANS Top 25

Tip 1 - Know what each artefact IS before you memorise contents. Many questions are definitional. If the question asks for a dictionary or taxonomy of weakness types, the answer is CWE. If it asks for a specific publicly known vulnerability identifier, it is CVE. If it asks about attack patterns, it is CAPEC. If it asks about an awareness list of web application risks, it is OWASP Top 10. If it asks for the most dangerous programming errors across all software types, it is the SANS/CWE Top 25. If it asks about a severity score, it is CVSS.

Tip 2 - Scope matters: web versus general software. OWASP Top 10 is web-application focused. CWE and the Top 25 cover all software (and now hardware), including C/C++ memory errors like buffer overflows and use-after-free that never appear in the OWASP web list. A question about embedded firmware or a desktop binary is pointing you at CWE/Top 25, not OWASP.

Tip 3 - OWASP Top 10 is NOT a standard or a complete checklist. If an answer option describes it as a compliance standard or implies that passing the Top 10 means the application is secure, that option is wrong. The ASVS is OWASP's verification standard; the Top 10 is awareness and prioritisation.

Tip 4 - Classify scenarios by symptom. Learn the tell-tale clues:
• User changes an ID in the URL and sees another customer's record = Broken Access Control / IDOR (CWE-639, CWE-862).
• Single quote in a form field causes a database error = SQL Injection (CWE-89).
• Script tag in a comment executes in other users' browsers = XSS (CWE-79), which under OWASP 2021 falls under A03 Injection.
• Stack trace with server paths shown to users = Security Misconfiguration / Information Exposure (CWE-209).
• Passwords stored as MD5 hashes = Cryptographic Failures (CWE-328).
• Application accepts a URL and fetches it, exposing an internal admin panel = SSRF (CWE-918).
• Library with a known CVE in the build = Vulnerable and Outdated Components.
• Serialised object from the client is reconstructed server-side = Software and Data Integrity Failures / Deserialisation (CWE-502).
• Attack went unnoticed for months = Logging and Monitoring Failures.
• Threat model was never done and a business logic flaw exists = Insecure Design.
• Copying a long string into a fixed-size array in C = Out-of-bounds Write / Buffer Overflow (CWE-787/120).
• Check a file, then open it, and the file changed in between = Race Condition / TOCTOU (CWE-367).

Tip 5 - Pick the mitigation that removes the root cause, not the symptom. For injection, the best answer is parameterised queries, not 'escape the single quote' or 'deploy a WAF'. For XSS, it is context-sensitive output encoding plus validation, not 'filter the word script'. For buffer overflows, it is bounds checking / safe functions / memory-safe language, not just enabling ASLR (which is defense in depth, not a fix). For broken access control, it is server-side authorisation checks on every request, not hiding links in the UI. WAFs, IDS and compensating controls are secondary; the exam prefers the secure coding fix when the question is in the implementation domain.

Tip 6 - Prefer allow-lists. Any time validation is the answer, 'allow-list (whitelist) validation' beats 'deny-list (blacklist)'. Also remember to canonicalise before validating (to defeat encoding tricks and path traversal).

Tip 7 - Watch for 'most', 'best', 'first', 'primary'. CSSLP questions often have several technically correct options. Choose the one that is most fundamental, earliest in the lifecycle, or addresses the broadest class. For example, when asked how to reduce the entire category of injection flaws across a codebase, 'adopt a secure coding standard and use a parameterised data-access layer' beats 'fix the reported SQL injection bug'.

Tip 8 - Remember the organisational owners and history facts. CWE is maintained by MITRE, sponsored by DHS/CISA. The Top 25 was created in 2009 by SANS and MITRE; it is now produced by MITRE annually using NVD/CVE data mapped to CWE and weighted by CVSS. OWASP is a non-profit open community; the Top 10 is updated roughly every three to four years (2013, 2017, 2021). The original three SANS categories were Insecure Interaction Between Components, Risky Resource Management and Porous Defenses.

Tip 9 - Know the 2021 OWASP changes. Expect questions on what is new (Insecure Design, Software and Data Integrity Failures, SSRF), what merged (XSS into Injection, XXE into Misconfiguration, Insecure Deserialisation into Integrity Failures), and what rose to number one (Broken Access Control). Also be aware of the sibling lists (Mobile Top 10, API Security Top 10, Proactive Controls) so you are not confused by an option referencing them.

Tip 10 - Connect the lists to tooling and process. If a question asks how to ensure or verify that code is free of Top 25 weaknesses, think SAST/DAST/SCA with CWE-tagged rules, code review checklists, security unit tests, and acceptance criteria in contracts. If it asks how to prioritise remediation of many CWE findings for a particular business, think CWSS/CWRAF or CVSS plus business impact - not simply 'fix in list order'.

Tip 11 - Do not confuse weakness with vulnerability with exploit. A weakness (CWE) in code becomes a vulnerability (CVE if public) when it is reachable and exploitable in a deployed product; an attack pattern (CAPEC) or exploit is how it is abused; a threat is the potential for that abuse. Questions that use these words precisely are testing exactly this chain.

Tip 12 - Think like the exam writer. CSSLP favours risk-based, lifecycle-wide, management-aware answers. When a scenario describes a Top 10 finding, the 'best' response usually includes fixing the code, adding a regression test, updating the secure coding standard or training so the class of defect does not recur, and feeding metrics back into the programme - not merely patching the single instance.

8. Quick Revision Summary

• OWASP Top 10 = web app risk awareness list; 2021 edition: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, SSRF.
• CWE = MITRE's dictionary of weakness types with unique IDs; the common language for tools, standards and the Top 25.
• SANS/CWE Top 25 = the most dangerous weaknesses across all software, originally in three categories (Insecure Interaction, Risky Resource Management, Porous Defenses), now data-driven from CVE/NVD.
• CVE = instance; CAPEC = attack pattern; CVSS = severity; CWSS/CWRAF = weakness prioritisation.
• Universal fixes: allow-list input validation, output encoding, parameterised queries, least privilege, complete mediation, secure defaults, strong vetted crypto, memory safety, secure error handling and logging, integrity verification.
• On the exam: identify the artefact type, match symptoms to the category, choose the root-cause coding fix, prefer allow-lists and server-side controls, and favour answers that prevent the whole class of defect across the SDLC.