Requests that look valid can still break business rules: skipped steps, repeated actions, impossible quantities or automated abuse.
- Document validation rules and business limits for each input and flow.
- Validate input against positive rules at a trusted service layer.
- Enforce step order, limits and atomic transactions in the business logic.
- Add anti-automation controls to flows that would cause harm if scripted.
Each requirement has a level. Level 1 holds the first-layer defenses (about a fifth of the standard), Level 2 adds what OWASP says most applications should strive for, and Level 3 adds defense-in-depth and harder-to-implement controls; meeting a level means meeting every requirement of the levels below it too. Cite a requirement with the version, for example v5.0.0-2.1.1.
V2.1 Validation and Business Logic Documentation · 3 requirements
V2.1.1 Level 1
Verify that the application's documentation defines input validation rules for how to check the validity of data items against an expected structure. This could be common data formats such as credit card numbers, email addresses, telephone numbers, or it could be an internal data format.
V2.1.2 Level 2
Verify that the application's documentation defines how to validate the logical and contextual consistency of combined data items, such as checking that suburb and ZIP code match.
V2.1.3 Level 2
Verify that expectations for business logic limits and validations are documented, including both per-user and globally across the application.
V2.2 Input Validation · 3 requirements
For the whole section: Prevent business-logic flaws with server-side invariants (guide) · Validate input safely and prevent regex denial of service (guide)
V2.2.1 Level 1
Verify that input is validated to enforce business or functional expectations for that input. This should either use positive validation against an allow list of values, patterns, and ranges, or be based on comparing the input to an expected structure and logical limits according to predefined rules. For L1, this can focus on input which is used to make specific business or security decisions. For L2 and up, this should apply to all input.
On this site: Run external programs without command or argument injection (guide) · Parse bounded JSON and XML into an explicit application schema (guide)
V2.2.2 Level 1
Verify that the application is designed to enforce input validation at a trusted service layer. While client-side validation improves usability and should be encouraged, it must not be relied upon as a security control.
On this site: Review trust boundaries in mobile and native clients (guide)
V2.2.3 Level 2
Verify that the application ensures that combinations of related data items are reasonable according to the pre-defined rules.
V2.3 Business Logic Security · 5 requirements
For the whole section: Prevent business-logic flaws with server-side invariants (guide)
V2.3.1 Level 1
Verify that the application will only process business logic flows for the same user in the expected sequential step order and without skipping steps.
V2.3.2 Level 2
Verify that business logic limits are implemented per the application's documentation to avoid business logic flaws being exploited.
V2.3.3 Level 2
Verify that transactions are being used at the business logic level such that either a business logic operation succeeds in its entirety or it is rolled back to the previous correct state.
On this site: Preserve business invariants under concurrent requests (guide)
V2.3.4 Level 2
Verify that business logic level locking mechanisms are used to ensure that limited quantity resources (such as theater seats or delivery slots) cannot be double-booked by manipulating the application's logic.
On this site: Preserve business invariants under concurrent requests (guide)
V2.3.5 Level 3
Verify that high-value business logic flows require multi-user approval to prevent unauthorized or accidental actions. This could include but is not limited to large monetary transfers, contract approvals, access to classified information, or safety overrides in manufacturing.
V2.4 Anti-automation · 2 requirements
For the whole section: Prevent business-logic flaws with server-side invariants (guide) · Stop account takeover with the right MFA and login defenses (guide)
V2.4.1 Level 2
Verify that anti-automation controls are in place to protect against excessive calls to application functions that could lead to data exfiltration, garbage-data creation, quota exhaustion, rate-limit breaches, denial-of-service, or overuse of costly resources.
On this site: Operate edge rules without hiding application defects (guide) · Contain cascading failures and rogue agents (guide) · Unbounded resource consumption (fix card)
V2.4.2 Level 3
Verify that business logic flows require realistic human timing, preventing excessively rapid transaction submissions.
Requirement IDs, levels and text are from the OWASP Application Security Verification Standard 5.0.0 (copyright © 2008-2025 The OWASP Foundation), unmodified, under the Creative Commons Attribution-ShareAlike 4.0 International License. Imported from release v5.0.0_release (commit 5cf9b03); license.
Guides on this site
Preserve business invariants under concurrent requests
Make a balance, reservation or approval rule hold when requests overlap, retry and fail halfway through.
Parse bounded JSON and XML into an explicit application schema
Separate parser capabilities from schema rules, reject ambiguous and coercible inputs, and implement the boundary in a complete Python project.
Bound API work, not just request counts
Protect availability and operating cost with limits on input, per-request work, concurrency, queues, and downstream spending.
Operate edge rules without hiding application defects
Tune WAF and abuse controls against legitimate traffic, parser behavior and measurable business effects.
Handle failures without leaking internals or weakening controls
Give callers a useful, bounded response while preserving protected diagnostic evidence and safe application state.
Verify webhook deliveries before acting
Verify the provider’s signature over the correct bytes, then apply replay, authorization, and idempotency controls before a business action.
Practice
- Race condition lab: Repair a balance check that races · Browser lab
- Webhook signature and replay lab: Repair a webhook handler that pays twice · Browser lab
- Business logic lab: Price an order without trusting the client · Browser lab
- XXE lab: Parse an uploaded invoice without resolving external entities · Browser lab
- Pickle deserialization lab: Load a session token without pickle · Browser lab
- Make a checkout transaction atomic · Local project
- Repair a real proxy and shared cache · Local project
- Parse bounded JSON and XML invoices safely · Local project
References
- V2 Validation and Business Logic (ASVS 5.0.0 source)
- OWASP Web Security Testing Guide: Business Logic Testing
- OWASP Input Validation Cheat Sheet
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.