Security Level 2 is the standard ASVS level for applications that face medium risk or handle sensitive data and transactions. It is designed for systems where authentication, validation, and injection resistance matter more because the business impact of compromise is higher. Teams use it when baseline controls are not enough.
Expanded Definition
Security Level 2, commonly abbreviated as ASVS Level 2, sits between baseline application hygiene and the stricter expectations used for high-value or high-consequence systems. It is the level most teams mean when they say an application must be secure enough for sensitive data, authenticated sessions, and transaction integrity without moving into the highest assurance tier.
Its boundary is practical: Level 2 is not a universal “secure enough” label, and it is not a shortcut for every risk profile. It assumes the application can be attacked by capable external users and that compromise would have real business impact. That makes authentication strength, input validation, session handling, and injection resistance central concerns. In guidance-vs-consensus terms, there is broad industry agreement that Level 2 is the default target for many internet-facing business applications, but the exact scope of “sensitive” varies by organisation and threat model.
A common misunderstanding is to treat the level as a one-time certification outcome. In practice, it is a design and assurance benchmark that must be interpreted against the application’s data sensitivity, trust boundaries, and transaction authority.
Examples and Use Cases
Security Level 2 appears most often where an application is important enough that weak controls would create material harm, but not so critical that every higher-assurance requirement is justified.
- A customer portal that processes account changes, billing updates, or password resets.
- An internal business application exposed to authenticated staff and third parties, where data integrity matters more than public read-only access.
- A web application handling personal data, order placement, or payment-adjacent workflows where injection and session abuse would be costly.
- An API supporting business transactions, where request validation and authorization checks must be reliable because misuse could alter records.
- A service integrating with non-human identities such as automation accounts or API clients, where OWASP Non-Human Identity Top 10 becomes relevant to credential handling and access scope.
The tradeoff is that Level 2 improves resilience without forcing the strictest controls everywhere. That makes it a practical fit for many production systems, but only if teams resist the temptation to stop at “we meet the level” and ignore application-specific abuse paths.
Security Implications
When Security Level 2 is misunderstood or under-implemented, the usual failure is not a dramatic total compromise. It is a steady accumulation of exploitable weaknesses: weak authentication flows, insufficient server-side validation, unsafely handled inputs, and session controls that are too permissive for the business value at stake.
Those gaps can lead to account takeover, injection-driven data access, transaction tampering, and loss of trust in records that other teams rely on. In medium-risk systems, the blast radius often extends beyond the initial application because the application becomes a stepping stone to customer data, operational data, or administrative functions. A practical indicator is that the system appears stable in normal use, yet small input or authorization mistakes still produce outsized effects.
For practitioners, the key warning sign is mismatch: if the application handles sensitive transactions but testing still treats it like a low-risk site, the control set will usually be too shallow for real-world abuse.
Domain and Governance Relevance
In application security governance, Security Level 2 is useful because it creates a shared baseline for scope, testing depth, and control expectations. It helps product, security, and engineering teams align on what “reasonable assurance” means for systems that are more than ordinary brochureware but not the organisation’s most critical crown jewels.
For identity-heavy systems, the relevance increases when the application delegates authentication, issues tokens, or relies on service accounts and automation. At that point, Level 2 is not just about application code quality. It also becomes a governance signal for how access is validated, how trust is granted, and how sensitive transactions are protected from misuse by both human and non-human actors. The important shift is that assurance must cover the whole transaction path, not only the visible login screen.
That makes Level 2 a control-selection aid as much as a security label. It tells teams where standard safeguards are no longer enough and where stronger validation discipline is warranted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Level 2 concerns sensitive app and automation access paths. |
| NHI-03 — Authorization and Access Scope | Medium-risk applications still fail when non-human access is overbroad. | |
| NHI-06 — Inventory and Ownership | Level 2 systems often rely on service accounts that need clear ownership. | |
| Recommendation — Apply NHI-01 to govern machine credentials that can reach Level 2 transactions. Constrain non-human access scope so automation cannot exceed its Level 2 duties. Track and assign ownership for every non-human identity used by Level 2 systems. | ||
| CIS Controls v8 | 6 — Access Control Management | Level 2 depends on stronger access control than baseline systems. |
| 16 — Application Software Security | The term is an ASVS application security level with clear control expectations. | |
| Recommendation — Enforce access control and remove unnecessary privileges from Level 2 applications. Test and harden application logic to meet Level 2 security requirements. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Level 2 systems are commonly exposed to application exploitation attempts. |
| Recommendation — Map exposed Level 2 apps to T1190 and hunt for exploit attempts against them. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Level 2 emphasises authenticated access and trust boundary discipline. |
| PR.IP — Information Protection Processes and Procedures | Level 2 is a governance baseline for application security assurance. | |
| DE.CM — Security Continuous Monitoring | Level 2 systems still need detection for abuse and drift after release. | |
| Recommendation — Use PR.AC to enforce stronger access checks around sensitive application actions. Use PR.IP to embed Level 2 assurance checks into secure development practice. Monitor Level 2 applications for injection, misuse, and authentication anomalies. | ||
