Incorrect Block Delimitation

Draft Base
Structure: Simple
Description

This vulnerability occurs when a developer fails to use explicit braces or delimiters to group multiple statements within a block, leading to unexpected program logic.

Extended Description

In programming languages like JavaScript, Python, or Go, braces, indentation, or keywords are sometimes optional for single-statement blocks. However, when you intend for multiple statements to execute together—such as within an `if` condition or a loop—omitting the explicit block delimiter means only the first statement is controlled by that condition. Subsequent statements execute unconditionally, creating a critical logic error. This error often manifests as a subtle bug where security-critical operations, like privilege checks or input validation, are bypassed. For example, an access control check might only guard a logging statement while allowing the actual data transaction to proceed without authorization. Always use explicit delimiters for multi-statement blocks to ensure your code's logic and security controls behave as intended.

Common Consequences 1
Scope: ConfidentialityIntegrityAvailability

Impact: Alter Execution Logic

This is a general logic error which will often lead to obviously-incorrect behaviors that are quickly noticed and fixed. In lightly tested or untested code, this error may be introduced it into a production environment and provide additional attack vectors by creating a control flow path leading to an unexpected state in the application. The consequences will depend on the types of behaviors that are being incorrectly executed.

Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 1
Phase: Implementation
Always use explicit block delimitation and use static-analysis technologies to enforce this practice.
Demonstrative Examples 2

ID : DX-181

In this example, the programmer has indented the statements to call Do_X() and Do_Y(), as if the intention is that these functions are only called when the condition is true. However, because there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.

Code Example:

Bad
C
c
This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.
In this example, the programmer has indented the Do_Y() statement as if the intention is that the function should be associated with the preceding conditional and should only be called when the condition is true. However, because Do_X() was called on the same line as the conditional and there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.

Code Example:

Bad
C
c
This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.
Observed Examples 1
CVE-2014-1266incorrect indentation of "goto" statement makes it more difficult to detect an incorrect goto (Apple's "goto fail")
References 1
The CLASP Application Security Process
Secure Software, Inc.
2005
ID: REF-18
Likelihood of Exploit

Low

Applicable Platforms
Languages:
C : SometimesC++ : Sometimes
Modes of Introduction
Implementation
Taxonomy Mapping
  • CLASP