CWE-1116 is source code containing comments that do not accurately describe or explain the code they are attached to.
Unlike many documentation entries nearby, MITRE allows this one to be used when mapping, as a base level weakness, with the standard advice to read the name and description carefully and not force a fit. The MITRE page also lists a mitigation, covered below.
How it happens
Code changes and the comment does not. A developer fixes a bug, tightens a check or swaps an argument and leaves the explanation above it untouched. Or the comment was wrong on day one, written from memory or copied from a similar function.
What an attacker gains
There is no direct gain. MITRE lists reduced maintainability and increased analytical complexity, and spells out the second: when a comment does not reflect the code, a reviewer is confused by the inconsistency, and it becomes harder and less efficient to validate that the code does what was intended.
The danger is the reviewer who trusts the comment. If the comment says the input is validated and it is not, the review stops at the comment.
# Vulnerable pattern: the comment promises a check that is not there
def read_file(name):
# name is sanitized by the caller, so it is safe to open directly
return open("/data/" + name).read()
If any caller does not sanitize, the comment has created false confidence. A safer version enforces the rule in the function instead of describing it.
import os
BASE = "/data"
def read_file(name):
path = os.path.realpath(os.path.join(BASE, name))
if not path.startswith(BASE + os.sep):
raise ValueError("path outside base directory")
with open(path) as f:
return f.read()
How to find it
The record lists no detection methods. In review, treat any comment that makes a security claim as a claim to verify, not a fact. Look hard at comments near code that changed recently.
How to fix it
MITRE's mitigation is short and applies in the implementation phase: verify that each comment accurately reflects what is intended to happen during execution of the code.
Some habits that make this stick:
- Update the comment in the same commit as the code.
- Prefer comments that explain why, which age better than comments that restate what.
- Replace claims with enforcement. If a comment says input is safe, make the code check it.
- Ask reviewers to check comments against code, not only code against tests.
Quick check
What does MITRE recommend?
To verify that each comment accurately reflects what is intended to happen during execution of the code.
Why is a wrong comment worse than no comment?
No comment makes a reader read the code. A wrong comment tells them they can skip it.
