Modification of Assumed-Immutable Data (MAID)

The application treats some piece of data as fixed and unchangeable by the client - a price, a role, a computed total, an internal flag - but the data actually travels through a client-controllable channel (a hidden form field, a cookie, a query parameter) and the server never re-validates it before trusting it again. This is a parameter-tampering pattern at heart: the bug isn't any single technical flaw so much as an incorrect trust assumption about where a value came from.

Confirming this requires knowing, application by application, which specific fields the server assumes are immutable and then testing exactly those - there's no generic signature, since the same technical action (modifying a form field or cookie) is completely benign for the vast majority of fields and only a bug for the specific ones the server wrongly trusts.

Manual testing informed by understanding the specific application's data flow - reading which values the client sends back and forth, and checking whether the server re-derives or re-validates each one rather than trusting the client's copy.

Tip: This is found by intercepting requests with a proxy and directly modifying any value the client is relied on to protect — the finding is confirmed the moment the server accepts a value it should have independently rejected.

Real-World Impact

Client-side enforcement of server-side security, tampering with data the client assumes is immutable, and UI elements that misrepresent what's actually happening all share the same root mistake: trusting the client to enforce something only the server can actually guarantee. A price, permission flag, or workflow state that's only checked or displayed client-side can be altered by anyone with browser developer tools or an intercepting proxy, regardless of how the UI presents it.

Content spoofing and UI misrepresentation compound this from the other direction — instead of an attacker bypassing a client-side check, a victim is shown misleading UI (a fake status, an altered display value, spoofed content) that leads them to trust something they shouldn't, which is a phishing-adjacent risk when it's exploited against other users rather than by them.

The underlying lesson across this whole family is the same one security engineering has repeated for decades: the client is not a trusted execution environment, and any security decision enforced only there should be assumed bypassed by a motivated attacker.

Prevention and Secure Design

Preventing Modification of Assumed-Immutable Data (MAID) takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Re-enforce every client-side check server-side. Anything the client validates, restricts, or displays for security purposes needs an equivalent, independent check on the server — the client-side version is a UX convenience, not a control.

Never trust client-supplied state for anything security-relevant. A price, permission flag, or workflow status the client sends back should be re-derived or re-validated server-side, not accepted as sent.

Sign or server-store anything that must stay immutable. Where a value genuinely needs to travel through the client unmodified, sign it (and verify the signature server-side) rather than hoping it isn't tampered with.

Design UI to reflect actual server state, not assumed state. A UI element showing a status or value should be sourced from a live, authoritative check, not a value the client is trusted to maintain correctly on its own.

Test with a proxy that can modify requests freely. Intercept and directly tamper with every client-side-enforced value to confirm the server independently rejects the invalid version.