Cwe Sans Top25

name: cwe-sans-top25 description: CWE/SANS Top 25 Most Dangerous Software Weaknesses -- classification, prevention patterns, and SAST integration for secure development tags: [cwe, security]

CWE/SANS Top 25 Most Dangerous Software Weaknesses

Overview

The CWE/SANS Top 25 is a curated list of the most prevalent and dangerous software weaknesses maintained by MITRE. Unlike OWASP (which focuses on web/API risks), CWE classifies root-cause weaknesses in software -- memory corruption, injection flaws, improper validation -- that lead to exploitable vulnerabilities. Each weakness has a unique CWE identifier used across CVE databases, SAST tools, and compliance frameworks.

This skill organizes the Top 25 by category, provides language-specific applicability, and maps each weakness to concrete prevention patterns and SAST rules. It is designed for developers performing code reviews, security engineers configuring static analysis, and architects establishing secure coding standards.

When to Use This Skill

• Performing security-focused code reviews on PRs
• Configuring SAST tools (Semgrep, CodeQL, Bandit) for a project
• Triaging CVEs and mapping them to root-cause weaknesses
• Building secure coding guidelines for a development team
• Evaluating third-party libraries for known weakness patterns
• Preparing for security audits or compliance reviews (SOC 2, ISO 27001)

How It Works

Step 1: Identify the Weakness Class

Determine which CWE category the suspected issue belongs to. Use the categories below to narrow down from broad symptoms (e.g., "crash on malformed input") to a specific CWE ID.

Step 2: Check CVSS and EPSS Scores

For known CVEs related to the weakness, look up:

• CVSS (Common Vulnerability Scoring System) -- severity score (0-10)
• EPSS (Exploit Prediction Scoring System) -- probability of exploitation in the wild (0-1)

# Query NIST NVD for a specific CVE
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2024-XXXXX" | \
  jq '.vulnerabilities[0].cve.metrics'

Step 3: Apply the Mitigation Pattern

Each CWE has a specific mitigation pattern. Apply the pattern from the relevant category below. Mitigations should be implemented at the earliest possible phase (design > implementation > testing).

Step 4: Verify with SAST Tools

Run static analysis to confirm the fix and prevent regression:

# Semgrep scan for Python security issues
semgrep scan --config p/python-security --config p/owasp-top-ten \
  --severity ERROR --error ./src/

# Bandit scan for Python-specific weaknesses
bandit -r ./src/ -ll -ii --format json -o bandit-report.json

# CodeQL analysis (GitHub Actions)
# Configured in .github/workflows/codeql.yml

Step 5: Add to Regression Tests

Write tests that specifically exercise the weakness vector to prevent reintroduction:

# Example: regression test for SQL injection (CWE-89)
import pytest

class TestSQLInjectionPrevention:
    """Regression tests ensuring parameterized queries are used."""

    @pytest.mark.parametrize("malicious_input", [
        "'; DROP TABLE users; --",
        "1 OR 1=1",
        "1 UNION SELECT * FROM credentials",
    ])
    async def test_user_lookup_rejects_injection(self, client, malicious_input):
        response = await client.get(f"/api/v1/users?search={malicious_input}")
        assert response.status_code in (200, 400)  # Must not cause 500
        # Verify no data leak from other tables
        data = response.json()
        assert "credentials" not in str(data).lower()

Weakness Categories and Key CWEs

Category 1: Memory Safety

These weaknesses affect languages without automatic memory management (C, C++, Rust unsafe blocks). They are the leading cause of critical remote code execution (RCE) vulnerabilities.

Prevention Pattern: Use memory-safe languages (Python, Rust, Go) where possible. For C/C++, enable compiler sanitizers (-fsanitize=address,undefined), use smart pointers, and enforce bounds checking.

Category 2: Injection

Injection weaknesses occur when untrusted data is sent to an interpreter as part of a command or query. They affect all languages that interface with databases, shells, or rendering engines.

Prevention Pattern: Use parameterized queries (SQL), context-aware output encoding (XSS), and avoid shell=True in subprocess calls. Never construct commands by string concatenation with user input.

Category 3: Authentication and Session Management

Prevention Pattern: Use established authentication frameworks, never hard-code secrets, enforce MFA on sensitive operations, and store credentials in secret managers (not config files or environment variables in source).

Category 4: Authorization and Access Control

Prevention Pattern: Implement default-deny authorization, check ownership on every resource access (see @owasp-api-top10 API1), enforce least-privilege, and use framework-level middleware rather than per-handler checks.

Category 5: Cryptography

Prevention Pattern: Use modern algorithms (AES-256-GCM, SHA-256+, Ed25519), OS-provided CSPRNG (secrets module in Python, not random), and bcrypt/argon2 for password hashing. Never implement custom cryptography.

Category 6: Input Validation and Resource Management

Prevention Pattern: Validate all input against strict schemas (type, length, format, range). Use allow-lists over deny-lists. Canonicalize file paths before access. Disable XML external entity processing by default.

Examples

Example 1: Preventing CWE-89 (SQL Injection) with Parameterized Queries

from sqlalchemy import select, text
from sqlalchemy.ext.asyncio import AsyncSession


# BAD: String concatenation -- vulnerable to CWE-89
async def search_users_insecure(db: AsyncSession, search_term: str):
    query = text(f"SELECT * FROM users WHERE name LIKE '%{search_term}%'")
    result = await db.execute(query)
    return result.all()


# GOOD: Parameterized query -- immune to CWE-89
async def search_users_secure(db: AsyncSession, search_term: str):
    query = text("SELECT * FROM users WHERE name LIKE :search")
    result = await db.execute(query, {"search": f"%{search_term}%"})
    return result.all()


# BEST: Use SQLAlchemy ORM -- parameterization is automatic
async def search_users_orm(db: AsyncSession, search_term: str):
    stmt = select(User).where(User.name.ilike(f"%{search_term}%"))
    result = await db.execute(stmt)
    return result.scalars().all()

Example 2: Preventing CWE-22 (Path Traversal) with Input Validation

import os
from pathlib import Path
from fastapi import APIRouter, HTTPException, status

router = APIRouter()

UPLOAD_DIR = Path("/app/uploads")


# BAD: No path validation -- vulnerable to CWE-22
@router.get("/files/{filename}")
async def get_file_insecure(filename: str):
    file_path = UPLOAD_DIR / filename  # filename could be "../../etc/passwd"
    return file_path.read_text()


# GOOD: Path canonicalization and containment check
@router.get("/files/{filename}")
async def get_file_secure(filename: str):
    # Reject obvious traversal attempts
    if ".." in filename or filename.startswith("/"):
        raise HTTPException(
            status_code=status.HTTP_400_BAD_REQUEST,
            detail="Invalid filename",
        )

    # Resolve to absolute path and verify containment
    file_path = (UPLOAD_DIR / filename).resolve()

    if not file_path.is_relative_to(UPLOAD_DIR.resolve()):
        raise HTTPException(
            status_code=status.HTTP_403_FORBIDDEN,
            detail="Access denied",
        )

    if not file_path.is_file():
        raise HTTPException(status_code=status.HTTP_404_NOT_FOUND)

    return file_path.read_text()

Example 3: SAST Rule for Detecting CWE-79 (XSS) with Semgrep

# .semgrep/rules/cwe-79-xss.yaml
rules:
  - id: cwe-79-jinja2-autoescape-disabled
    patterns:
      - pattern: jinja2.Environment(..., autoescape=False, ...)
    message: >
      Jinja2 autoescape is disabled (CWE-79). This allows cross-site scripting
      when rendering user-controlled data. Set autoescape=True or use
      select_autoescape().
    severity: ERROR
    metadata:
      cwe:
        - "CWE-79: Improper Neutralization of Input During Web Page Generation"
      confidence: HIGH
      category: security
    languages: [python]

  - id: cwe-79-markupsafe-bypass
    patterns:
      - pattern: markupsafe.Markup($USER_INPUT)
    message: >
      Wrapping user input in Markup() bypasses HTML escaping (CWE-79).
      Only use Markup() for trusted, pre-sanitized content.
    severity: WARNING
    metadata:
      cwe:
        - "CWE-79: Improper Neutralization of Input During Web Page Generation"
      confidence: MEDIUM
      category: security
    languages: [python]

  - id: cwe-79-fastapi-html-response
    patterns:
      - pattern: |
          from fastapi.responses import HTMLResponse
          ...
          HTMLResponse(content=<... $USER_INPUT ...>)
    message: >
      User input rendered directly in HTMLResponse without escaping (CWE-79).
      Use a template engine with autoescape or html.escape().
    severity: ERROR
    metadata:
      cwe:
        - "CWE-79: Improper Neutralization of Input During Web Page Generation"
      confidence: MEDIUM
      category: security
    languages: [python]

# Run the custom rule alongside built-in rules
semgrep scan --config .semgrep/rules/ --config p/python-security \
  --severity ERROR --error ./src/

Best Practices

Do This

• Use memory-safe languages (Python, Rust, Go) to eliminate entire weakness categories (CWE-787, CWE-125, CWE-416)
• Parameterize all database queries -- use ORM query builders instead of raw SQL strings
• Canonicalize file paths with Path.resolve() and verify containment before access
• Use secrets module (not random) for any security-sensitive random values
• Configure SAST tools (Semgrep, Bandit) in CI/CD to block PRs introducing known weakness patterns
• Write regression tests that exercise known attack vectors for each fixed weakness
• Use allow-lists for input validation -- define what is valid rather than what is invalid
• Disable XML external entity processing by default in all XML parsers
• Hash passwords with bcrypt or argon2id, never with MD5 or SHA-1 alone

Don't Do This

• Do not concatenate user input into SQL, shell commands, or HTML templates
• Do not use subprocess.run(..., shell=True) with user-controllable arguments
• Do not store secrets in source code, environment variables checked into repos, or config files
• Do not use random module for tokens, passwords, or cryptographic keys
• Do not disable autoescape in Jinja2 or mark user input as safe/trusted
• Do not trust file extensions for upload validation -- check content type and magic bytes
• Do not suppress SAST findings without documented justification and security review
• Do not implement custom cryptographic algorithms or protocols

Security Checklist

Memory Safety (CWE-787, CWE-125, CWE-416, CWE-476)

• C/C++ code compiled with -fsanitize=address,undefined in CI
• Smart pointers used instead of raw pointers where applicable
• Bounds-checked array access in all performance-critical loops
• Null pointer checks before all dereferences of external data

Injection (CWE-89, CWE-79, CWE-78, CWE-94)

• All SQL queries use parameterized statements or ORM query builders
• HTML templates use auto-escaping (Jinja2 autoescape=True)
• Subprocess calls use argument lists (never shell=True with user input)
• No eval(), exec(), or dynamic code execution with untrusted input

Authentication and Credentials (CWE-287, CWE-798, CWE-522)

• No hard-coded credentials in source code (scanned by SAST and git-secrets)
• Secrets stored in dedicated secret managers (GCP Secret Manager, Vault)
• Password hashing uses bcrypt or argon2id with appropriate work factors
• Authentication bypass paths audited (default credentials, magic tokens removed)

Authorization (CWE-862, CWE-863, CWE-269)

• Default-deny authorization policy on all API endpoints
• Resource ownership verified on every object access (BOLA prevention)
• Privilege escalation paths audited (role assignment, admin functions)
• Least-privilege principle applied to service accounts and IAM roles

Input Validation and File Handling (CWE-20, CWE-22, CWE-434, CWE-611)

• All user input validated against strict schemas (type, length, format)
• File paths canonicalized and checked for containment within allowed directories
• File uploads validated by content type, magic bytes, and size limits
• XML parsers configured to disable external entity processing
• CSRF tokens required on all state-changing endpoints

Cryptography (CWE-327, CWE-330, CWE-916)

• Only modern crypto algorithms in use (AES-256-GCM, SHA-256+, Ed25519/X25519)
• secrets module used for all security-sensitive random generation
• TLS 1.2+ enforced for all network communication
• No custom or hand-rolled cryptographic implementations

Related Skills

• @owasp-top10 -- Web application security risks with broader scope than CWE
• @owasp-api-top10 -- API-specific security risks mapped to CWE root causes
• @api-security-patterns -- Implementation patterns for securing FastAPI/Python backends

Additional Resources

• CWE Top 25 (2023 Edition)
• MITRE CWE Database
• Semgrep Rule Registry
• NIST NVD (National Vulnerability Database)
• EPSS (Exploit Prediction Scoring System)
• OWASP Secure Coding Practices Quick Reference