There is a concept in computing which is known by various names, but perhaps the most common is the Robustness Principle. It can be summarised as:

Be liberal in what you accept, and strict in what you produce.

This is originally related to TCP implementations but has since been applied to almost all higher level protocols over time. The general concept is that when implementing a protocol you should be as careful as you can in what you generate, so that even the simplest of implementations can easily interpret your output; and that when interpreting what another implementation has sent to you, do your best to do something useful with what you receive, even if it is not the most correct of messages.

This is a good principle to work to, but like all good things, it can be taken to extremes; and in extremis it is a gun loaded and pointed at your head. In general, being strict in what you produce can't really result in damage, but taking liberal acceptance to extremes is what causes confusing and unusual attacks being possible. An excellent example of just how bad things can get when you're a little to liberal can be found at Bouke van der Bijl's Blog related to attacking Redis, Memcached, and Elasticsearch bound to localhost.

A useful corollary to the robustness principle is do not trust user input.

For your homework this week, go and have a look at something you have which processes input, generates output, and/or speaks any protocols. (This ought to be almost any software you have written). Look over that software's implementation of input data sanitisation or protocol implementations and decide if there's anything you could do to improve matters. Then improve them and feel better about yourself for a little bit.