D3-DLV Domain Logic Validation: What It Hardens and How to Verify It

A value can be the right type and inside the declared range and still be wrong for the business or the process it drives. D3-DLV Domain Logic Validation is the MITRE D3FEND countermeasure for that gap. D3FEND defines it as "Validation of variable state in the context of the domain application", and describes it as checking the type, value and range of a variable while taking into account the current application in its business domain. It sits in the Harden tactic under Source Code Hardening, and it has one child technique, D3-OLV Operational Logic Validation, for control logic in operational technology. This card covers what the technique asks of code, the ATT&CK relationship D3FEND infers for it, where it is implemented in web applications and PLC programs, and how to verify it. It is written for application security engineers, control system engineers and reviewers.

Key takeaways

• Domain logic validation asks "does this value make sense here?" Generic validation checks format and type; domain validation checks the value against business rules, the current state and related data.
• It must run where the decision is made. OWASP's business logic data validation test and the Top 20 Secure PLC Coding Practices both say client or HMI checks alone can be bypassed.
• D3FEND's only ATT&CK link is inferred. The D3FEND page shows an inferred relationship to T1505.001 SQL Stored Procedures through the shared Subroutine artefact, and no direct mapping.
• The rules have to be written down first. OWASP ASVS 5.0 V2.1 requires documented validation and business logic limits; code cannot enforce rules nobody has defined.
• Scanners rarely find these gaps. MITRE CWE notes that business logic errors are hard to find with automated tools, so verification relies on abuse case tests and review.

D3-DLV at a glance

How it works

Ordinary input validation answers "is this a well-formed integer?". Domain logic validation answers "is this integer a sensible quantity, price, setpoint or step for this user, in this state, right now?". In practice that means three kinds of check inside the subroutine that acts on the value:

• Value in business range: a refund cannot exceed the original payment; a tank setpoint cannot exceed what the vessel can physically hold.
• Consistency between related items: ASVS 5.0 requirement V2.2.3 asks that combinations of related data items are reasonable according to predefined rules, such as a delivery date after an order date.
• State and sequence: a value valid in one state may be invalid in another. ASVS V2.3.1 requires business flows to run in the expected step order without skipping steps. D3-OLV makes the same point for controllers: a value can be cross-checked against the operating state as well as against a general range.

The OWASP Web Security Testing Guide test WSTG-BUSL-01 gives a useful example of why format checks are not enough: an identifier can pass every format rule and still be logically invalid. It also stresses that data should be checked again at hand-off points between systems rather than trusted because it arrived from another internal component.

Weaknesses it addresses

These are members of the CWE-840 Business Logic Errors grouping. CWE marks CWE-840 itself as a grouping that should not be used to map real vulnerabilities, so record findings against the member weakness. For the wider class, see the Business Logic Vulnerabilities Guide.

ATT&CK techniques D3FEND relates to D3-DLV

Relationship type: inferred. D3FEND lists no direct ATT&CK mapping for D3-DLV. Its page shows one inferred, experimental relationship, derived because both the countermeasure and the technique touch the same digital artefact (a Subroutine, of which a stored procedure is one kind). Checked November 2026.

See the T1505 Server Software Component Defensive Guide for that behaviour. The Top 20 Secure PLC Coding Practices, which D3FEND cites, map their validation practices to ATT&CK for ICS techniques such as T0836 Modify Parameter and T0806 Brute Force I/O. That is the reference document's mapping, not a D3FEND one, but it is the more useful link for OT teams: see MITRE ATT&CK for ICS T0836 Modify Parameter and T0806 Brute Force I/O.

Where it is implemented

Business applications and APIs

• Service or domain layer: rules live next to the operation (refund, transfer, booking), not in the browser. ASVS V2.2.2 requires validation at a trusted service layer.
• Authoritative data: WSTG-BUSL-01 recommends validating against the authoritative source when the rule depends on it, for example a live balance rather than a nightly copy.
• Transactions and locking: ASVS V2.3.3 and V2.3.4 require all-or-nothing transactions and locking for limited resources, so two valid requests cannot together break a rule.
• Database code: stored procedures that change money, stock or entitlements carry the same checks as application code, which is the link D3FEND draws through the Subroutine artefact.

PLC and control logic

The Top 20 Secure PLC Coding Practices (version 1.0, dated 15 June 2021 on the project site) devote practices 6 to 12 to validation:

The document cites the Oldsmar, Florida water incident, where an input thousands of times higher than normal was entered, as the case for setting physical limits in the PLC rather than in HMI scripts. For controller hardening in general, see the PLC Security Guide and the sibling card D3-OLV Operational Logic Validation.

Implementation steps

1. Write the rules down. For each high-value operation or controlled variable, record valid ranges, related-field rules, state conditions and per-user and global limits (ASVS V2.1.1 to V2.1.3). Engineers and process owners agree them together.
2. Find every entry and hand-off point. Map where values enter (forms, APIs, HMI writes, Modbus registers, batch files) and where they pass between systems, as WSTG-BUSL-01 describes.
3. Centralise the checks. Put each rule in one domain function or PLC routine that all paths call, so a new API or HMI screen cannot skip it.
4. Decide the failure action. Reject and log in business applications; in control logic choose a safe default or last valid value plus an alarm, as practice 8 suggests, after a process safety review.
5. Test in report-only mode first. Log would-be rejections against live traffic or a process simulator for a period, tune rules that block legitimate edge cases, then enforce.
6. Roll back by rule, not by switch. Keep each rule individually configurable so a faulty rule can return to logging without removing the others.

How to verify it works

• Abuse case tests: tamper with quantities, prices, identifiers and step order through an intercepting proxy, as WSTG-BUSL-01 describes. Each should be rejected server-side.
• Bypass the front end: send out-of-range values straight to the API or, in a test bench, straight to the PLC register, skipping the UI or HMI limits.
• Concurrency tests: fire parallel requests against limited resources to check locking and limits hold.
• Unit tests from the rule catalogue: each documented rule has a passing and a failing test case.

Limits, bypasses and failure patterns

• Client-only or HMI-only limits: both reference sources warn that front-end checks are bypassed by crafted requests or network traffic.
• Trusting internal data: values from another internal system are skipped on the assumption they were validated upstream; WSTG-BUSL-01 advises checking at each hand-off.
• Stale reference data: rules checked against copies refreshed overnight allow limits to be exceeded through rapid transactions.
• Rules in many places: each channel reimplements the check slightly differently and one path is missed.
• Logic attacks by legitimate users: domain validation cannot stop an authorised operator entering a value that is inside the agreed limits but still harmful; that needs approval workflows (ASVS V2.3.5) and monitoring.

Framework mapping

Related countermeasures

• Child: D3-OLV Operational Logic Validation, the control logic form of this technique.
• Siblings under Source Code Hardening: D3-IRV Integer Range Validation and D3-VTV Variable Type Validation handle the generic range and type checks that domain rules build on; D3-PV Pointer Validation and D3-CS Credential Scrubbing cover other code-level hardening.

For general input handling, see the Input Validation and Output Encoding Guide.

Practitioner checklist

• Keep a catalogue of domain rules for every high-value operation and controlled variable.
• Enforce every rule server-side or in the PLC, never only in the UI or HMI.
• Route all channels through one validation function per rule.
• Re-validate data at hand-off points between systems.
• Validate against current authoritative data where a rule depends on balances, stock or state.
• Use transactions and locking for limited resources.
• Define a safe failure action and alarm for out-of-range process values.
• Write pass and fail tests for each rule and include business logic cases in penetration tests.

Standards and references

• MITRE D3FEND: Domain Logic Validation (D3-DLV)
• Top 20 Secure PLC Coding Practices Project: Top 20 Secure PLC Coding Practices
• OWASP: WSTG-BUSL-01 Test Business Logic Data Validation
• OWASP: Application Security Verification Standard 5.0
• MITRE CWE: CWE-840 Business Logic Errors
• NIST: SP 800-53 Rev 5, Security and Privacy Controls

Related NHI Mgmt Group resources: Business Logic Vulnerabilities Guide · OWASP ASVS Guide · PLC Security Guide · Secure Coding Guide · MITRE D3FEND Guide