How do developers prevent modification of assumed-immutable data (MAID)?

Why MAID becomes dangerous when code assumes immutability

Assumed-immutable data is safe only if the runtime truly prevents later writes or if the code treats every reference as potentially changeable. The failure mode is not just a bad value, it is a trust break, because a value that was validated earlier can be altered before it is used for an access check, integrity decision, or security-sensitive branch.

That is why defensive code treats external inputs, shared objects, and returned references as mutable by default. Copying before storage, avoiding exposure of internal state, and re-reading values after untrusted code executes are all ways to keep the program’s trust boundary aligned with the data’s real lifetime.

Where MAID bugs usually appear in real code

MAID problems show up where a program validates once and then reuses the same object later. Common examples include request objects, permission maps, policy decisions, cached configuration, and parsed structures that are handed to other code. If the same object instance can be changed in place, earlier validation no longer proves anything about the value at use time.

The issue is especially sharp when the object crosses a boundary, such as being passed into a library, exposed through a getter, shared between threads, or stored in a cache. If the code relies on referential stability rather than copying or defensive wrapping, later mutation can silently change the meaning of an earlier security decision.

A useful rule is to assume any object can be altered once control leaves the current function. That mindset pushes developers toward immutable types where available, deep copies where needed, and explicit revalidation at the point of use rather than at the point of receipt.

How to design code so later mutation cannot change security decisions

The safest pattern is to minimise shared mutable state and keep security-critical decisions close to the data they depend on. If a value determines authorisation, integrity, or routing, the code should either hold a private copy or re-derive the decision from trusted source data rather than trusting an object that may have been handed elsewhere.

When the language offers immutable collections or value types, use them for security-relevant data structures. When it does not, make copies before storing, return copies instead of internal references, and avoid APIs that expose mutable internals by design. For security-sensitive comparisons, recalculate or revalidate after callbacks, plugin hooks, or other untrusted execution points.

Developers should also be careful with concurrency. A race does not need to be malicious to create a security issue, because another thread can change the value between validation and use. If the code depends on a value staying the same, the implementation needs synchronisation, ownership discipline, or snapshot semantics, not just a comment that the data is “effectively immutable”.

Risk and Threat Considerations

MAID flaws are high-value because they can turn a previously trusted decision into a stale one. An attacker who can influence shared state, or even benign racing code, may be able to alter a field after validation and before enforcement, which can bypass checks that were correct at the time they ran.

Failure mechanism: The program validates one object instance, then later uses the same mutable instance after untrusted code, another thread, or a callback changes the data in place. That breaks the assumption that the checked value and the used value are identical.

Impact: The altered value can subvert authorisation logic, integrity checks, feature flags, policy enforcement, or downstream business rules. In the worst case, a stale trusted object becomes a control bypass, not just a logic bug.

Practitioner Guidance

What to verify: Check whether any security-sensitive object is passed by reference, cached, or exposed through getters after validation. If the object can be changed outside the validating function, treat the validation as non-binding until the point of use.

Decision rule: If the value influences access, trust, or integrity, prefer an immutable representation or a private copy; if you cannot enforce that, re-read and revalidate immediately before the sensitive action. Do not rely on “we do not mutate it here” unless the language or runtime makes that guarantee real.

Practitioner takeaway: MAID is fundamentally a trust-timing problem, so the control objective is to make the security decision and the used value inseparable, either by immutability, private copies, or point-of-use revalidation.

Related resources from NHI Mgmt Group

• Guide: CWE Top 25 Guide
• How do developers prevent assumed-immutable data from being stored in writable memory?
• How do developers prevent Authentication Bypass by Assumed-Immutable Data?
• What causes modification of assumed-immutable data (MAID)?
• Modification of Assumed-Immutable Data (MAID)