Order of checks is a security property

Root the phone, modify the app, and send a legitimate-looking delivery with something extra attached: a price, a cash amount set to zero, an assignee pointing at yourself. A naive implementation spreads the payload into the update and the driver has just given himself a raise. This is mass assignment, and at the sync boundary it is the write path, so this is where it has to be stopped.

The defence is an allowlist of fields a device may author. Status, timestamps, recipient name, field notes, proof media. Price, cash amount, assignee and customer are not in it and never will be. A device naming them is not in conflict with anything; it is attacking, and it is refused outright.

Here is the part that is easy to miss. The allowlist check has to run before conflict resolution, not after. Without that ordering, an attacker wraps the price change inside a genuine delivery. The delivery is physical, so it wins under the core rule, and the malicious field rides along on a legitimate decision. Same allowlist, same resolver, same logic, and the vulnerability is purely in the sequence.

That generalises: authorization must happen before anything acts on the thing. Strip what the caller is not allowed to touch before any logic decides what wins, or a legitimate action becomes a smuggling vehicle for an illegitimate one. There is a unit test asserting the rejection beats even the field-wins rule, because this is exactly the kind of property a well-meaning refactor breaks two years later while all the other tests stay green.