CWE-656 is a protection whose strength depends heavily on staying secret, so that knowing the algorithm or the key data is enough to defeat it. It hits anything where the defense is "nobody will find this": custom encodings, hidden fields, keys compiled into executables, undocumented endpoints.
How it happens
MITRE notes that obscurity can be a small part of defense in depth, since it creates more work for an attacker. The danger is using it as the primary protection. If an attacker can reverse engineer the inner workings, nothing else stands in the way.
The record lists four real cases:
- CVE-2006-6588: reliance on hidden form fields in a web application. The developer did not consider that hidden fields can be processed using a modified client.
- CVE-2006-7142: a hard-coded cryptographic key stored in an executable program.
- CVE-2005-4002: another hard-coded cryptographic key in an executable.
- CVE-2006-4068: hard-coded hashed username and password values in client-side script, allowing offline brute-force attacks.
A short vulnerable pattern:
# Vulnerable: the "secret" ships with every copy of the program
KEY = b"s3cr3t-k3y-1234"
def check(token: str) -> bool:
return token == hash_with(KEY, "admin")
Anyone with the binary can extract the key.
What an attacker gains
MITRE says the security mechanism can be bypassed easily, with possible impact on confidentiality, integrity and availability. Because the secret ships to every user, a single reverse engineer can defeat every deployment.
How to find it
The record lists no detection methods. Practical checks: search the code and shipped artifacts for hard-coded keys, passwords and fixed tokens; inspect form fields and client-side script for values that the server trusts; and ask of each control, if the attacker had the full source, would it still hold?
How to fix it
MITRE's mitigations:
- Always consider whether knowledge of your code or design is enough to break it. Reverse engineering is a highly successful discipline and financially feasible for motivated adversaries.
- When available, use publicly vetted algorithms and procedures, which have had more analysis and testing. This matters most for encryption and authentication.
Keep secrets out of code, generate per-deployment keys, and validate on the server everything the client sends.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is obscurity ever acceptable?
As one small layer on top of real controls, yes. MITRE says it can create more work for an attacker. It is a significant risk as the main protection.
Why are hidden form fields not a control?
The client is under the user's control. A modified client can send any value, so the server must validate it.
