Key Takeaways: Application Security

A one-page reference. Reread before an exam or before Chapter 13. Dense by design.

Core vocabulary (memorize cold)

Term One-line definition
Secure SDLC (SSDLC) Building security activities into every phase of development, not bolting on a pre-launch audit
Shift left Move security earlier (design/code) where defects are far cheaper to fix
OWASP Top 10 A ranked list of categories of application risk — awareness & prioritization, not a standard or test
CWE Common Weakness Enumeration — catalog of specific weakness types, each with an ID (e.g., CWE-89 SQLi)
Input validation Check incoming data matches the expected shape (allowlist), server-side, and reject the rest
Output encoding Transform data so the destination interpreter treats it as inert (context-specific)
Security requirement A specific, verifiable statement of what software must do/never do to be secure
Threat modeling (app) Analyzing a design (e.g., with STRIDE) to find what could go wrong before building it
SAST Static analysis of code at rest — finds insecure patterns/taint paths; points to a line
DAST Dynamic testing of the running app from outside — finds exploitable runtime behavior
SCA Software Composition Analysis — inventories third-party deps & checks for known vulns
Dependency risk Risk from components you import, especially transitive (deps of your deps)
SBOM Software Bill of Materials — machine-readable inventory of all components (intro Ch.23, full Ch.29)

The OWASP Top 10 → defense (program level)

# Category Mechanism Program-level defense
A01 Broken Access Control Authz missing or trusts client-supplied IDs (IDOR) Enforce authz server-side, every request, default-deny, keyed to identity (Ch.17)
A02 Cryptographic Failures Sensitive data unencrypted/weakly protected Encrypt in transit & at rest; hash passwords properly; never roll your own (Ch.4–5)
A03 Injection Untrusted input parsed as a command (concatenation) Separate code from data: parameterized queries, safe APIs; validate as a 2nd layer
A04 Insecure Design A security control was never specified Threat modeling + security requirements (no scanner finds a missing control)
A05 Security Misconfiguration Defaults, verbose errors, unneeded features Hardened baseline (Ch.11), least-functionality, config-as-code
A06 Vulnerable & Outdated Components Running deps with known CVEs (Log4Shell) SCA + fast patching (Ch.23) + SBOM (Ch.29)
A07 Identification & Auth Failures Weak auth, no anti-automation, bad sessions Vetted auth frameworks, lockout, session mgmt (Ch.16, 13)
A08 Software & Data Integrity Failures Trusting unverified code/data/updates Signed artifacts, verified deps, trusted pipeline (Ch.29, 31)
A09 Logging & Monitoring Failures Security events not logged/watched Log security-relevant events with context → SIEM (Ch.21)
A10 SSRF App fetches attacker-chosen URLs (incl. internal) Allowlist outbound destinations; block internal ranges (Ch.13)

The ten reduce to a few habits: validate input · separate code from data · verify integrity · enforce authz server-side · configure to a baseline · log the right events. Web-specifics (SQLi/XSS/CSRF/SSRF) are dissected in Chapter 13.

Two patterns that prevent the most bugs

   INPUT ─▶ [INPUT VALIDATION] ─▶ logic ─▶ [OUTPUT ENCODING] ─▶ destination
            allowlist, SERVER-SIDE,         make inert FOR        (HTML / SQL /
            parse to expected type          THIS interpreter       shell / URL)
  • Validate on the way IN; encode on the way OUT. Different moments, different jobs — run both (defense in depth). Neither replaces the other.
  • Positive validation (allowlist) > denylist — you can define what's allowed; you can't list every bad input.
  • Client-side validation is NOT a security control (client is attacker-controlled) — re-do it server-side.
  • Encoding is context-specific — HTML ≠ JS ≠ URL ≠ SQL; wrong-context encoding = no protection.
  • Parameterized queries move the code/data boundary into the driver — the robust fix for injection.

SAST vs DAST vs SCA — when to use what

SAST DAST SCA
Examines Your code, at rest Running app, from outside Third-party dependencies
SDLC phase Code (early) Test (needs deployed app) Build + continuous
Points to a line? Yes No (a request) Yes (component/version)
Main weakness False positives False negatives Only as good as its vuln DB
Answers "do we use Log4j, where?" No Maybe Yes

Use all three + human review + threat modeling. Tools find recognizable bugs; design & business-logic flaws need threat modeling (the 4th blind spot). Don't drown devs in unfiltered output — tune, prioritize by risk, gate on the high-confidence/high-severity subset (Ch.31 ci_gate).

Log4Shell (CVE-2021-44228) — the anchor in one box

  • What: crafted string in logged input → vulnerable Log4j fetches & runs remote code. CVSS 9.8.
  • Why brutal: a deeply transitive dependency in countless products — orgs didn't know they ran it.
  • The decisive question wasn't "how does it work?" but "do we use it, and WHERE?"
  • Lesson: the bottleneck is discovery, not patching → inventory deps (SBOM), monitor advisories, patch fast. You cannot protect what you don't know you have (Ch.1), in the language of dependencies.
  • Recurs: Ch.23 (prioritization), Ch.29 (SBOM/supply chain), Ch.31 (pipeline), Ch.40 (full case).

Threat modeling with STRIDE

Letter Threat Example control
Spoofing Pretending to be someone Authentication on the endpoint
Tampering Altering data TLS in transit, integrity at rest
Repudiation Denying an action, no proof Audit logging with identity + timestamp
Information disclosure Leaking data Authorization, encoding, least privilege
Denial of service Degrading availability Size/type/rate limits
Elevation of privilege Gaining rights you shouldn't Server-side authz; never execute uploads

Four questions: What are we building? What can go wrong (STRIDE)? What do we do about it? Did we do a good job? Deliverable = verifiable security requirements, not a diagram. Threat-model anything crossing a trust boundary or touching sensitive data — even "simple" features (they hide the worst flaws).

Certification crosswalk

Concept CompTIA Security+ (ISC)² CISSP domain
Secure SDLC / shift left 2.0 / 3.0 / 4.0 Software Development Security
OWASP Top 10 / injection / XSS 2.3 App attacks; 3.0 Architecture Software Development Security
Input validation / output encoding 3.0 Secure coding Software Development Security
SAST / DAST / SCA 4.0 Security Operations (tooling) Software Development Security; Security Assessment
Supply-chain / dependency risk 2.0 Threats; 5.0 GRC Security & Risk Management; Software Dev Security
Threat modeling / STRIDE 1.0 / 3.0 Security Architecture & Engineering

Project additions this chapter

  • Meridian program: one-page Secure SDLC policy (gates per phase: threat-model → SAST → SCA+secret scan → DAST → log+monitor).
  • bluekit toolkit: appsec.py — scan_dependencies(reqs) (SCA in miniature; hand-traced vs Log4Shell).

Common pitfalls

  • Treating the OWASP Top 10 as a one-time test instead of risks to manage continuously.
  • Relying on client-side validation, or on input validation alone (you also need output encoding).
  • "Fixing" injection by stripping characters (denylist) instead of parameterizing.
  • Deleting a hard-coded secret without rotating it (version control keeps history → it leaked).
  • Ignoring transitive dependencies; declaring victory after Log4Shell without adopting SCA/SBOM.
  • Drowning developers in unfiltered scanner output until they ignore the findings that matter.
  • Skipping threat modeling on "simple" features — where the worst design flaws hide.