Skip to content

4. Review Code-Level Vulnerabilities (overview)

Chapter 4 - Review Code-Level Vulnerabilities

Code-level security analysis is the final layer of the methodology.

The methodology chapter defined structure, modeled subsystem threats, traced data, and checked business logic. This part moves into the code that implements the security controls. The reviewer now asks how individual variables, functions, libraries, parsers, and framework calls can turn attacker-controlled input into security impact.

The goal is not to memorize every bug class. The goal is to learn a repeatable pattern: trace the data, identify the trust boundary, find the unsafe assumption, and verify the control.

How to Use the Mini-Chapters

Each vulnerability family below has its own standalone chapter. Every mini-chapter follows the same teaching pattern:

  1. What the flaw is — definition and CWE mapping where applicable.
  2. Vulnerability characteristics — where the pattern appears in real codebases (features, sinks, weak controls).
  3. Attack payloads (or abuse scenarios) — representative test patterns for authorized security testing.
  4. Language-specific sinks and dangerous APIs — per-language libraries, calls, and system interfaces to search for, each with a short code sample.
  5. Sample vulnerable code in Python — one focused example to study first.
  6. Step-by-step review walkthrough — how to trace the flaw and why each step matters.
  7. Risk impact analysis — what can go wrong for users, data, and the business.
  8. Vulnerable examples in other languages — always Java and C# first; then, when applicable, JavaScript, HTML, and Go; then SQL, Shell, and C. The Sample Vulnerable Code section always uses Python for the primary walkthrough.
  9. Fix: safer patterns and libraries — real code using vetted APIs, with Important notes per language.
  10. Verify during review — evidence to collect before you file a finding.
  11. Reference — official documentation links for the libraries and standards cited in the fix section.

The archive article Secure Coding in Practice remains available as background reading; mini-chapters do not link to it in their reference sections.

Code diversity across examples

Examples are intentionally varied across chapters. The same function call (for example subprocess with shell=True, jwt.decode(..., verify_signature=False), or a generic ping wrapper) should not repeat in another mini-chapter unless this page shows a vulnerable pattern paired with a fixed contrast in the same section. Prefer different libraries, business scenarios, and sink APIs so readers see a wider attack surface—not one canonical snippet copied everywhere.

Input Validation, Injection, and Parsing

Cryptography

Sessions, Requests, and Access Control

Information Disclosure

File and Path Handling

Framework and Configuration

Insecure Coding Practices

Logging and Supply Chain

Core Review Habits

Most code-level findings still start with data flow:

  • Where does the data come from?
  • What code transforms it?
  • Where is it used (the sink)?
  • Is the data attacker-controlled?

Separate input validation from output encoding. Validation decides whether data is acceptable for the application. Encoding makes data safe for a specific output context (HTML, SQL, shell, URL).

When you finish a mini-chapter, record source, sink, missing control, impact, and a test that proves the fix.

Next: Secure Implementations and Configuration

After code-level patterns, continue with: