Chapter 30 Quiz: Application Security¶

B — A03: Injection

In OWASP Top 10 2021, Cross-Site Scripting (XSS) was consolidated into A03: Injection (previously it had its own category in 2017). The attack is stored XSS — malicious script is persisted in the database and executed in victims' browsers on page load, stealing session cookies. The fix is output encoding and Content Security Policy (CSP).

C — SAST — Static Application Security Testing

SAST analyzes source code, bytecode, or binary at rest (without execution) to identify security weaknesses. It is ideal for early pipeline integration (shift-left). DAST tests running applications by sending malicious inputs from the outside. IAST instruments the running application to observe behavior from within. SCA identifies vulnerable third-party library dependencies.

C — Spoofing

STRIDE categorizes threats as: Spoofing (impersonating another entity), Tampering (modifying data), Repudiation (denying actions), Information Disclosure (exposing data), Denial of Service, Elevation of Privilege. Impersonating a service to intercept communications is Spoofing. The mitigation is mutual TLS (mTLS) authentication between microservices.

C — Tune the WAF rules by analyzing false positive patterns, creating exceptions for legitimate traffic, and iterating — accepting some false positives as a trade-off for protection

WAF tuning is an ongoing process. The correct response to high false positives is analysis and rule refinement: identify which rules trigger on legitimate traffic, create path/parameter-specific exceptions, validate the change doesn't introduce bypass gaps, and iterate. Disabling (A) or detection-only mode (B) eliminates protection. WAF effectiveness requires investment in ongoing tuning.

B — API3: Broken Object Property Level Authorization (Excessive Data Exposure)

OWASP API3 (2023) covers scenarios where APIs return more data than the client requires, relying on the client to filter sensitive fields. This exposes sensitive properties to anyone intercepting the response. The fix is server-side field filtering — return only the fields explicitly required by the consuming application, not full object representations.

C — Software Composition Analysis (SCA)

SCA tools (e.g., Snyk, OWASP Dependency-Check, Dependabot) scan project dependency manifests (package.json, requirements.txt, pom.xml) against vulnerability databases (NVD, OSV) to identify known CVEs in third-party libraries. SAST analyzes custom code, not dependencies. DAST tests running applications. SCA is the primary defense against Log4Shell-style supply chain vulnerabilities.

B — Security Champions program — developers trained in AppSec who serve as security liaisons within each team

A Security Champions program identifies security-interested developers within each team and provides them with dedicated AppSec training, access to security tooling, and a community of practice. Champions perform first-line security reviews, advocate for secure design within their teams, and escalate to the central AppSec team for complex issues. This scales security coverage without requiring a security review for every pull request.

B — During the Design phase, before code is written

Threat modeling is most valuable and least costly during the Design phase because: (1) architectural flaws are cheapest to fix on a whiteboard, (2) design changes are free compared to code refactoring, and (3) security requirements identified early can be built in rather than bolted on. IBM's cost-of-a-bug research shows defects found in design cost 10–100× less to fix than those found in production.

C — Business logic flaws and runtime authorization failures visible only when the application executes

DAST tests the running application by sending crafted requests and observing responses. It can discover: IDOR (can user A access user B's data?), authentication bypass, session management issues, and server-side behavior that only manifests at runtime. SAST cannot evaluate runtime behavior, business logic, or multi-request authorization flows. DAST complements SAST by covering runtime attack surface.

B — SAST and SCA in CI pipeline, mandatory threat modeling at design, security unit tests, and developer security training

Shift-left means moving security activities earlier in the development lifecycle — towards the left of the timeline. The core practices are: SAST/SCA in every build (automated, early feedback), threat modeling at design (before code), security-focused unit/integration tests (in developer workflow), and developer training (building security knowledge at the source). Post-launch activities (WAF, bug bounty, pen testing) are necessary but represent shift-right, not shift-left.