An off-by-one error occurs when code miscalculates a boundary or index by exactly one unit, causing it to access memory or data one position beyond or before…
An off-by-one error occurs when code miscalculates a boundary or index by exactly one unit, causing it to access memory or data one position beyond or before the intended range. While often dismissed as a minor logic bug, these errors can lead to buffer overflows, information disclosure, data corruption, or denial of service depending on context and what lies at the adjacent memory location.
Off-by-one errors typically arise from confusion about whether loop conditions or array indices are inclusive or exclusive, or from incorrect arithmetic when calculating buffer sizes and boundaries. Common sources include:
- Loop conditions using <= instead of < (or vice versa), causing one extra iteration
- Forgetting that array indices start at 0, not 1
- Miscalculating the size of a buffer when allocating or copying data (e.g., allocating length bytes instead of length + 1 for a null terminator)
- Incorrect boundary checks that allow access to index n when the valid range is 0 to n-1
The error is subtle because the code often appears logically sound and may pass initial testing, only manifesting under specific input sizes or edge cases.
In languages with manual memory management (C, C++), off-by-one errors in buffer operations can trigger buffer overflows, potentially allowing arbitrary code execution or information leaks. In managed languages (Python, Java), they typically cause index-out-of-bounds exceptions or incorrect data processing. In web applications, they may lead to accessing unintended array elements, skipping validation checks, or exposing adjacent data structures. The severity depends on what data or code lies at the adjacent memory location and whether bounds checking is in place.
def process_user_ids(user_list):
# Intended to process indices 0 through len(user_list)-1
for i in range(len(user_list) + 1): # Off-by-one: should be range(len(user_list))
user_id = user_list[i]
print(f"Processing user {user_id}")Why it's vulnerable:
The loop iterates one extra time, attempting to access user_list[len(user_list)], which is beyond the valid index range and raises an IndexError. In other contexts, this could read uninitialized or adjacent memory.
def process_user_ids(user_list):
# Correctly iterate from 0 to len(user_list)-1
for i in range(len(user_list)):
user_id = user_list[i]
print(f"Processing user {user_id}")<?php
function copy_data($source, $dest_size) {
// Intended to copy up to dest_size bytes
for ($i = 0; $i <= $dest_size; $i++) { // Off-by-one: should be $i < $dest_size
$dest[$i] = $source[$i];
}
return $dest;
}
?>Why it's vulnerable:
The loop condition $i <= $dest_size allows one extra iteration, writing to $dest[$dest_size], which exceeds the allocated buffer and may overwrite adjacent memory or cause undefined behavior.
<?php
function copy_data($source, $dest_size) {
// Correctly iterate from 0 to dest_size-1
for ($i = 0; $i < $dest_size; $i++) {
$dest[$i] = $source[$i];
}
return $dest;
}
?>for (item in collection) loops over manual index arithmetic where possible.
malloc(length + 1) for null-terminated strings).
i < length rather than i <= length unless you have a specific reason for the inclusive boundary.
strncpy, bounds-checked APIs) or higher-level abstractions over manual pointer arithmetic.
Look for crash logs or error messages indicating out-of-bounds array access, unexpected IndexError or segmentation faults in production, or data corruption in adjacent fields or structures. If you observe that a feature works correctly for most input sizes but fails or behaves oddly at specific boundaries (e.g., exactly at buffer size, or when processing the last element), an off-by-one error may be present.
