CWE-642

CWE-642 is an entry in a public catalog of programming errors that lead to security vulnerabilities. This catalog is called the Common Weakness Enumeration, or CWE for short, and is maintained by the US organization MITRE. Each error type is assigned a fixed number there, so that experts worldwide can talk about the same problem. The number 642 stands for the following error: a program stores important information in a place that the user can modify themselves. Later, the program relies on this information as if it were untouchable. The English title is “External Control of Critical State Data”.

State data refers to information that a program must remember between two steps. Who is currently logged in, what is in the shopping cart, whether someone is an administrator. If this information ends up in the user’s browser instead of on the provider’s server, the user can rewrite it. That is exactly what CWE-642 describes.

Why a price of 1 euro suddenly looks legitimate

The classic case is an online shop that sends the price of an item along in a hidden form field. Anyone who opens the page with the browser’s developer tools can turn 899 euros into a 1. If the shop forwards this value to the payment process without checking it, the damage is real. Such errors have repeatedly been found in real shops, even among major retailers.

The case involving permissions is even more serious. If an application stores a data field in the browser with the content “role=user”, it is often enough to change it to “role=admin”. The attacker needs no password and no special tools for this. They only need to modify data that already belongs to them.

It is important to distinguish this from vulnerabilities where someone breaks in from outside. With CWE-642, nobody breaks in. The program voluntarily handed the user the keys and hopes they won’t use them. That is why this vulnerability is considered a design flaw, not a typo in the code.

Trust in the wrong place

Web applications are split across two sides. One part runs on the provider’s server, the other in the user’s browser. Only the server part is protected; the browser part effectively belongs to the user. Everything sent there can be altered: form fields, cookies, address bars, hidden parameters.

Developers still like to offload state data to the browser because it saves server memory and makes the application simpler. The error occurs in the next step: the returning data is no longer checked. Picture it like a coat check that doesn’t hand out numbers, but instead lets every guest write on a slip of paper which jacket belongs to them.

The countermeasure is unspectacular. Critical data stays on the server, and the browser at most receives a random reference number. If data must be sent outward after all, it is given a cryptographic signature, i.e. a tamper-proof seal of authenticity. And even then, the server re-checks with every request whether the user is actually allowed to perform the action.

Where the number shows up in reports

You will mainly encounter CWE-642 in security advisories. When a software vulnerability is published, it receives a CVE number as a unique case identifier, plus a CWE number for the underlying error type. This makes it possible to evaluate which error types are especially common.

Automated scanning tools also use the catalog. Programs that search source code for vulnerabilities report their findings with CWE numbers. Within companies, these reports land with development teams, who then have to prioritize them. This is the standard approach for audits against standards like ISO 27001 or for security testing before a product launch.

A common misconception: some people consider the problem solved because the connection is encrypted. However, encryption only protects data against third parties during transport. It offers no protection whatsoever against the user themselves, who alters the data before sending it. That is why CWE-642 also continues to appear regularly in modern apps and in interfaces between programs.