Every piece of software that takes inputs contains a de facto recognizer for accepting valid or expected inputs and rejecting invalid or malicious ones. This recognizer code is often ad hoc, spread throughout the program, and interspersed with processing logic (a "shotgun parser"). This lends the processing logic to exploitation and programmers to false assumptions of data safety.
Apply full recognition to inputs before processing them!
Unneeded computing power in input handling code is a hand-out to attackers. Reduce computing power needed for your protocols, reduce parsing exposure to the necessary minimum! The power that is not there cannot be hijacked.
Once created, the glut of computing power cannot be destroyed, because of backward compatibility; repackaging of insecurity goes on forever. Fight it at the origin: reduce the computing power demands of your protocol!
Hard-to-parse protocols require complex parsers. Complex, buggy parsers become weird machines for exploits to run on. Help stop weird machines today: Make your protocol context-free or regular!
Protocols and file formats that are Turing-complete input languages are the worst offenders, because for them, recognizing valid or expected inputs is UNDECIDABLE: no amount of programming or testing will get it right.
A Turing-complete input language destroys security for generations of users. Avoid Turing-complete input languages!
When software components communicate, the messages they send to each other must be interpreted by receivers exactly as they were meant by senders, otherwise ambiguity and therefore insecurity ensues. Protocol endpoints must therefore contain computationally equivalent parsers.
But, for non-deterministic pushdown automata (ambiguous context-free grammars) and above, the task of validating parser equivalence is UNDECIDABLE: no amount of programming or testing will get it right.
Ensure computational equivalence of protocol endpoints: use only regular and context-free protocols!