System Design Cases
OWASP Top 10 (2021)
OWASP Top 10 (2021) — concept page covering all 10 vulnerability classes with 3 deep-dive scenarios: A03 SQL injection (vulnerable string-concat vs parameterized queries), A01 Broken Access Control (IDOR — First American 2019 style), A10 SSRF to AWS IMDS leading to IAM credential theft (Capital One 2019). Topology: Attacker -> WAF/LB (edge) -> API + AuthZ + Audit Logger (app) -> Postgres + Secrets Vault + AWS IMDS + S3 (internal). 2 ADRs on the WAF node: (1) defense-in-depth — где какая защита, mapping each OWASP item to the right layer (WAF / API Gateway / App / Infra / Supply chain / Observability), (2) A03 SQL injection — prepared statements vs ORM vs string concat with concrete code rules and gotchas (LIKE, IN, ORDER BY identifiers).
OWASP Top 10 as an engineering risk map
The OWASP Top 10
is an awareness document for web application risk categories, not a certification checklist or a complete threat model. Each category maps to design, implementation, verification, monitoring, and response controls.Security invariants
- TOP10-C1: OWASP Top 10 is an awareness and risk-category document, not a complete application security standard or certification checklist.
- TOP10-C2: The 2025 categories begin with Broken Access Control, Security Misconfiguration, and Software Supply Chain Failures.
- TOP10-C3: Cryptographic Failures, Injection, and Insecure Design require distinct data, interpreter, and design controls.
- TOP10-C4: Authentication Failures are lifecycle failures across authenticators, recovery, sessions, throttling, and reauthentication rather than only weak passwords.
- TOP10-C5: Software or Data Integrity Failures require authenticated provenance, update, serialization, and replay boundaries.
- TOP10-C6: Logging and Alerting Failures concern actionable protected security telemetry, while Mishandling of Exceptional Conditions concerns safe behavior under errors and partial failure.
Trust-boundary map
| Component | Responsibility |
|---|---|
client | Legitimate Client |
attacker | Adversarial Client or Supplier |
edge | Web Edge and Request Boundary |
application | Web Application |
authorization | Object and Function Authorization |
authentication | Authentication and Session Controls |
configuration | Hardened Configuration Baseline |
supply-chain | Dependency and Build Integrity Gate |
crypto-service | Approved Cryptography and Key Policy |
input-validator | Typed Input and Safe Interpreter Boundary |
design-review | Threat Model and Abuse-Case Review |
integrity-verifier | Software and Data Integrity Verifier |
database | Protected Data Store |
security-log | Security Logging and Alerting |
error-handler | Bounded Exceptional-Condition Handler |
Topology edges represent authenticated or otherwise explicit communication paths. Responses reuse those physical paths in reverse; no response-only or bypass edges are added.
Executable scenarios
a01-broken-access-control — A01 Broken Access Control
Authorization is enforced server-side for every object, function, tenant, and field instead of trusting routes, hidden UI, or caller-supplied identifiers.
a02-security-misconfiguration — A02 Security Misconfiguration
Secure defaults, minimal services, repeatable configuration, safe headers, and drift detection replace one-time manual hardening.
a03-supply-chain-failures — A03 Software Supply Chain Failures
Dependencies and artifacts are inventoried, pinned, verified against provenance and policy, and monitored throughout their lifecycle.
a04-cryptographic-failures — A04 Cryptographic Failures
Data classification drives encryption and key management; approved authenticated encryption does not compensate for exposed keys or missing authorization.
a05-injection — A05 Injection
Untrusted data remains data through parameterized APIs, typed parsers, contextual output handling, and explicit interpreter boundaries.
a06-insecure-design — A06 Insecure Design
Threat modeling, abuse cases, security requirements, and architecture review address missing controls that scanning an implementation cannot invent.
a07-authentication-failures — A07 Authentication Failures
Phishing resistance, throttling, secure recovery, session rotation, and reauthentication protect the full authentication lifecycle.
a08-integrity-failures — A08 Software or Data Integrity Failures
Code, updates, serialized data, and control messages are accepted only from authenticated sources under explicit integrity and replay policy.
a09-logging-alerting-failures — A09 Security Logging and Alerting Failures
Security-relevant events carry stable context, are protected from tampering, reach actionable alerts, and never log secrets by default.
a10-exceptional-conditions — A10 Mishandling of Exceptional Conditions
Timeouts, partial failures, resource exhaustion, and unexpected state transitions are bounded, fail safely, and preserve invariants.
Operational and failure rules
- Every rejection path fails closed at the component that owns the decision; infrastructure failure is never converted into authentication, authorization, or integrity success.
- Retries preserve stable transaction identity, replay detection, bounded freshness, and audit context. A retry does not erase a prior success or compromise signal.
- Concurrent validation branches are independent checks. Completion requires every mandatory branch, and no check substitutes for another.
- Logs contain decision metadata and stable identifiers, not credentials, bearer tokens, cryptographic keys, or sensitive payloads.