CWE-233 describes a product that does not properly handle the case where the expected number of parameters, fields, or arguments is not provided, or where those parameters are undefined. It is a parent entry. Several narrower weaknesses sit under it, and they are covered in the posts that follow in this series.
It applies to any language and any technology. If your code takes input from a caller, a request, a message or a command line, it can happen to you.
How it happens
A developer writes a handler that expects three fields. The tests always send three fields. In production, a client sends two, or sends one with no value, or sends a field the handler has never heard of.
If the code indexes into the input without checking, the result depends on the language. It might crash, read a default that was never meant to be used, or carry on in a half-initialized state. MITRE lists the consequence as an integrity problem: the program lands in an unexpected state.
Common triggers include optional form fields treated as required, array style arguments that are shorter than assumed, and API calls where a missing key is read as an empty string.
What an attacker gains
The record names one consequence: integrity, through an unexpected state. That sounds mild, but an unexpected state is the starting point for most logic bugs. A missing field can skip a check that was supposed to run after it. The more specific child weaknesses add crashes and, in low level code, memory problems.
How to find it
MITRE lists two detection methods for this entry.
- Fuzzing. Generate many diverse inputs, including ones with fields removed, duplicated or blank, and watch for crashes and odd behavior.
- Automated static analysis (SAST). Some instances can be found by modeling data flow through the source without running it.
You can add a cheap manual test. For each endpoint or function, send the input with each field removed one at a time. Then send it empty.
How to fix it
The record has no mitigation list for this entry, so the advice here is general practice that follows from the description.
- Decide which parameters are required and reject the request early when one is missing.
- Give optional parameters an explicit, safe default instead of relying on whatever the runtime supplies.
- Decide what happens to parameters you do not recognize, and make that behavior deliberate.
- Add the "field removed" cases to your unit tests so the behavior stays fixed.
Quick check
Is a missing parameter always a security problem?
No. Many cases are plain bugs. It becomes a security problem when the unexpected state skips a check, crashes a service, or changes what the program does with data.
Which two detection methods does MITRE list?
Fuzzing and automated static analysis.
