Unchecked input is where the serious failures begin

Most severe problems trace back to a value that was accepted without ever being questioned.

The pattern is consistent and worth internalising. Something arrives from outside, it is treated as though the site had produced it, and it is then used to make a decision or to build an instruction. The failure is not that the value was wrong. It is that nobody ever asked whether it was right. A system that questions its inputs turns a would be crisis into a rejected request and a line in a log. A system that does not can be steered by whoever is supplying the values.

The defensive habit is stated positively rather than as a list of dangers. Decide in advance what shape each incoming value may take, what range it may occupy, and what happens when it does not comply. Prefer describing what is permitted over cataloguing what is not, because a list of permitted things is finite and a list of prohibited things never is. Keep values that came from outside conceptually separate from values you produced, so the distinction survives long enough to matter.

The same reasoning applies to permission, which is really input checking wearing a different coat. A request that identifies which record it wants is supplying a value from outside, and the fact that a visitor could ask for it is not evidence that they may have it. Checking identity and checking entitlement are separate questions, and answering only the first is one of the most common gaps in otherwise careful work.