Introduction
Web application security is a property of architecture, implementation, configuration, delivery, and operations. This guide follows the ten categories in the authoritative OWASP Top 10:2021 awareness document. It is a starting point for engineering judgment—not a complete verification standard, audit, or substitute for a threat model.
Client
Input
Application
Validation
Authorization
Policy
Business logic
Invariants
Data
Protection
01 / Broken Access Control
Access control fails when a user can act outside the permissions intended for their identity, role, resource, or tenant. Authentication establishes who a subject is; authorization must still decide what that subject may do on every protected operation.
| Lens | Engineering guidance |
|---|---|
| Why it matters | Unauthorized reading, modification, deletion, privilege escalation, or cross-tenant access can undermine confidentiality and integrity. |
| Typical risk | Unauthorized reading, modification, deletion, privilege escalation, or cross-tenant access can undermine confidentiality and integrity. |
| Identify | Inventory protected actions and resources, test role and ownership boundaries, review server-side policy enforcement, and add negative authorization tests to delivery pipelines. |
| Mitigate | Deny by default, centralize policy where practical, enforce ownership and tenant boundaries server-side, use short-lived sessions, and log rejected high-value actions. |
02 / Cryptographic Failures
Cryptographic failures occur when sensitive data lacks appropriate protection in transit or at rest, or when keys, algorithms, and protocols are selected or managed poorly.
| Lens | Engineering guidance |
|---|---|
| Why it matters | Exposure of credentials, health records, personal data, tokens, or business information can create lasting harm even after the original flaw is fixed. |
| Typical risk | Exposure of credentials, health records, personal data, tokens, or business information can create lasting harm even after the original flaw is fixed. |
| Identify | Classify sensitive data, trace where it travels and persists, inspect transport settings, key handling, backups, logs, and accidental plaintext copies. |
| Mitigate | Minimize retained sensitive data, use current well-reviewed libraries and protocols, separate key management from data, rotate secrets, and define lifecycle and deletion rules. |
03 / Injection
Injection occurs when untrusted data is interpreted as part of a command, query, template, or expression rather than handled strictly as data.
| Lens | Engineering guidance |
|---|---|
| Why it matters | The application may disclose or alter data, bypass intended logic, or cause an interpreter to perform unintended operations. |
| Typical risk | The application may disclose or alter data, bypass intended logic, or cause an interpreter to perform unintended operations. |
| Identify | Map every boundary where input reaches an interpreter, review query construction, use static analysis where useful, and test representative invalid and adversarial inputs in authorized environments. |
| Mitigate | Use parameterized APIs, safe framework abstractions, contextual output encoding, allow-list validation, least-privileged service accounts, and avoid constructing commands from input. |
04 / Insecure Design
Insecure design describes missing or ineffective security controls at the design level. Correctly implemented code cannot compensate for a workflow that never defined abuse cases, trust boundaries, or safe failure behavior.
| Lens | Engineering guidance |
|---|---|
| Why it matters | Attackers may exploit legitimate features, business rules, or sequences in ways the product model did not anticipate. |
| Typical risk | Attackers may exploit legitimate features, business rules, or sequences in ways the product model did not anticipate. |
| Identify | Use threat modeling, abuse stories, architecture review, data-flow diagrams, and tests for business invariants before and during implementation. |
| Mitigate | Define security requirements, separate trust zones, limit high-risk workflows, add rate and value constraints, choose safe defaults, and revisit threats as the system changes. |
05 / Security Misconfiguration
Security misconfiguration is unsafe deployment or runtime state: unnecessary services, permissive policies, verbose errors, default accounts, missing headers, exposed storage, or inconsistent environment settings.
| Lens | Engineering guidance |
|---|---|
| Why it matters | A secure implementation can become exposed through one weak environment, forgotten endpoint, or overly broad cloud permission. |
| Typical risk | A secure implementation can become exposed through one weak environment, forgotten endpoint, or overly broad cloud permission. |
| Identify | Maintain environment baselines, scan infrastructure and headers, compare environments, review public exposure, and inspect error behavior and default configuration. |
| Mitigate | Automate hardened configuration, remove unused features, apply least privilege, keep environments reproducible, prevent sensitive error detail, and continuously detect drift. |
06 / Vulnerable and Outdated Components
Applications inherit risk from frameworks, libraries, runtimes, containers, and transitive dependencies whose versions or provenance are unknown or unsupported.
| Lens | Engineering guidance |
|---|---|
| Why it matters | A known weakness in a widely deployed component can create a large attack surface and urgent remediation pressure. |
| Typical risk | A known weakness in a widely deployed component can create a large attack surface and urgent remediation pressure. |
| Identify | Maintain a software inventory and lockfiles, monitor authoritative advisories, identify unsupported versions, and determine whether vulnerable code paths are actually reachable. |
| Mitigate | Reduce dependencies, use trusted sources, update continuously in small increments, define patch ownership and response targets, verify signatures where available, and retest after upgrades. |
07 / Identification and Authentication Failures
These failures weaken identity proof, session management, credential recovery, or protection against automated attempts. A valid session must remain securely bound to the right user and lifecycle.
| Lens | Engineering guidance |
|---|---|
| Why it matters | Account takeover can expose private data and allow actions that appear legitimate to downstream systems. |
| Typical risk | Account takeover can expose private data and allow actions that appear legitimate to downstream systems. |
| Identify | Review sign-in, enrollment, recovery, logout, session rotation, token storage, and concurrency; monitor abnormal authentication patterns without logging secrets. |
| Mitigate | Use established identity systems, multifactor authentication where appropriate, secure password storage, throttling, generic failure responses, session rotation, and explicit revocation. |
08 / Software and Data Integrity Failures
Integrity failures arise when code, updates, build artifacts, serialized data, or automation inputs are trusted without adequate verification.
| Lens | Engineering guidance |
|---|---|
| Why it matters | Compromise of a delivery path or trusted artifact can distribute malicious behavior broadly while appearing to come from a legitimate source. |
| Typical risk | Compromise of a delivery path or trusted artifact can distribute malicious behavior broadly while appearing to come from a legitimate source. |
| Identify | Map the software supply chain, review CI/CD permissions, verify artifact provenance and signatures, protect branches and release workflows, and inventory deserialization boundaries. |
| Mitigate | Use trusted registries, pinned dependencies, protected pipelines, isolated build roles, signed or verifiable artifacts, review gates, and safe serialization formats. |
09 / Security Logging and Monitoring Failures
Security-relevant events may be absent, ambiguous, unprotected, or never connected to an actionable alert and response process.
| Lens | Engineering guidance |
|---|---|
| Why it matters | Intrusions and misuse can persist undetected, while responders lack the evidence needed to determine impact and recover confidently. |
| Typical risk | Intrusions and misuse can persist undetected, while responders lack the evidence needed to determine impact and recover confidently. |
| Identify | Define detection use cases, simulate authorized suspicious events, verify end-to-end alert delivery, assess retention and clock consistency, and confirm logs exclude secrets. |
| Mitigate | Log meaningful identity, authorization, administrative, and integrity events; protect logs from tampering; tune alerts; assign response ownership; and rehearse incident procedures. |
10 / Server-Side Request Forgery (SSRF)
SSRF occurs when an application fetches a remote resource using attacker-influenced destinations without enforcing where the server is permitted to connect.
| Lens | Engineering guidance |
|---|---|
| Why it matters | The server may reach internal services, cloud metadata, or trusted network locations that are not accessible to an external client. |
| Typical risk | The server may reach internal services, cloud metadata, or trusted network locations that are not accessible to an external client. |
| Identify | Inventory URL-fetching features, trace redirects and DNS resolution, review egress paths, and test destination restrictions in an isolated, explicitly authorized environment. |
| Mitigate | Allow-list required schemes and destinations, normalize and validate addresses, re-check redirects, block private and metadata ranges, segment fetch services, restrict egress, and avoid returning raw upstream responses. |
From awareness to an engineering program
The categories are most useful when they change routine engineering work: requirements include security invariants, design reviews include abuse cases, code review covers trust boundaries, delivery verifies dependencies and configuration, and operations can detect and respond. Teams should use deeper standards such as OWASP ASVS when they need testable application-security requirements.