When you use public transportation, you assume that the train will stop at the station, the doors will open and close and, in case you press the "stop" button in the bus, it will actually do allow you to exit at the next station. All this works, because of – quite often unspoken – agreements that we assume to be kept and adhered to by others or by the technology we rely on. What applies to your country though may not be valid all over the world.
While it would most probably cause quite some chaos not to rely on those agreements in everyday life or earn us at least some very strange looks, from the paranoid perspective of a person being interested in security I come to realize more and more often how fragile the world's everyday workflows are. And how easy it is on the other hand to recover many smaller problems whenever our assumptions turned out to be wrong.
Implicit assumptions are a problem
But, of course, assumptions can also be abused. As has been proven various times by TV reporters or security researchers and trainers, entering a secured area or openly removing (personal) items is a lot easier than one might believe! Often merely conveying confidence is already enough. Maybe supported by clothes fitting the purpose, for instance by wearing a warning-vest in case you want to go into a construction area or even simply having a batch stating a made-up company name while carrying around a toolbox, supporting the notion of being a technician. I just recently saw a TV report where a secretary, being ever friendly, kept the elevator doors open so the "technician" would not have to carry the heavy IT-equipment down the stairs or wait for the next cabin ...
What holds true for the so called real life also applies to software and the processes modeled in it. When writing software, sometimes the implicit assumptions turn out to be quite a problem: Just because it doesn't make sense to supply an invalid bank account when transferring funds or provide a birthday in the future doesn't mean nobody would do it. The most interesting question is not why that might happen but how the application will deal with it? That makes it vital to not only test whether or not the application works with valid data but also that it complains in a defined way in case it can not process the inputas expected.
While the two given examples above only raise the question of how to validate the user input – and if need be how to reject it, other workflow related issues are harder to test for and may not be that obvious to begin with.
Tricky captchas
Let's have a look at a very simple yet common example: To stop spammers from abusing a contact form, the typical approach these days is to add a captcha. While that is not a problem per-se from the security perspective – we're not talking about accessibility here – it requires a workflow to be implemented: The captcha code needs to be generated as well as its distorted visual representation, the code has to get stored in a session and it has to be verified when the form is submitted back to the application.
On first glance it may seem like a good idea to combine the code generation and image output into one file. So whenever the webpage with the protected form gets loaded, the captcha image gets displayed along. Well, that's only true until you decide to disable images within the browser. Now the form gets displayed without the captcha image being requested, thus we end up not having a captcha code in the user session. Once submitted and depending on the actual implementation, we might end up comparing a non existing value from the session with an empty value from the form. Due to the typecasting nature of PHP where a NULL value would be equal to empty (unless a type safe comparison is used), the captcha-check could be avoided, violating the assumption an attacker would actually have to solve the captcha to submit the form successfully.
In a world of assumptions actual security cannot exist. If something is vital to the business logic of your application, verify it. Turn an assumption into knowledge. Or accept the fact it may not be as you assumed and act accordingly.