Omitted Break Statement in Switch
Weakness ID: 484 (Weakness Base)Status: Draft
+ Description

Description Summary

The program omits a break statement within a switch or similar construct, causing code associated with multiple conditions to execute. This can cause problems when the programmer only intended to execute code associated with one condition.

Extended Description

This can lead to critical code executing in situations where it should not.

+ Time of Introduction
  • Implementation
+ Applicable Platforms







+ Likelihood of Exploit


+ Detection Methods

White Box

Omission of a break statement might be intentional, in order to support fallthrough. Automated detection methods might therefore be erroneous. Semantic understanding of expected program behavior is required to interpret whether the code is correct.

Black Box

Since this weakness is associated with a code construct, it would be indistinguishable from other errors that produce the same behavior.

+ Demonstrative Examples

Example 1

(Bad Code)
Example Language: Java 
int month = 8;
switch (month) {

case 1: print("January");
case 2: print("February");
case 3: print("March");
case 4: print("April");
case 5: print("May");
case 6: print("June");
case 7: print("July");
case 8: print("August");
case 9: print("September");
case 10: print("October");
case 11: print("November");
case 12: print("December");
println(" is a great month");
Example Languages: C and C++ 
int month = 8;
switch (month) {

case 1: printf("January");
case 2: printf("February");
case 3: printf("March");
case 4: printf("April");
case 5: printff("May");
case 6: printf("June");
case 7: printf("July");
case 8: printf("August");
case 9: printf("September");
case 10: printf("October");
case 11: printf("November");
case 12: printf("December");
printf(" is a great month");

Now one might think that if they just tested case 12, it will display that the respective month "is a great month." However, if one tested November, one notice that it would display "November December is a great month."

+ Potential Mitigations

Phase: Implementation

Omitting a break statement so that one may fall through is often indistinguishable from an error, and therefore should be avoided. If you need to use fall-through capabilities, make sure that you have clearly documented this within the switch statement, and ensure that you have examined all the logical possibilities.

Phase: Implementation

The functionality of omitting a break statement could be clarified with an if statement. This method is much safer.

+ Weakness Ordinalities
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class398Indicator of Poor Code Quality
Development Concepts (primary)699
Research Concepts1000
ChildOfWeakness ClassWeakness Class670Always-Incorrect Control Flow Implementation
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPOmitted break statement
+ Content History
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable Platforms, Description, Detection Factors, Relationships, Other Notes, Taxonomy Mappings
2008-11-24CWE Content TeamMITREInternal
updated Applicable Platforms, Demonstrative Examples, Description, Detection Factors, Name, Other Notes, Potential Mitigations, Weakness Ordinalities
Previous Entry Names
Change DatePrevious Entry Name
2008-11-24Omitted Break Statement