Security breaches are always the most exciting headline in the news. People love talking about hackers and the black market because it’s really cool and sleek, although the reality is that hacking is less about hackers and more about this.

That is what makes the US Postal Service API security flaw particularly interesting. Specifically, this weakness allowed people to access data their account wasn’t supposed to see by simply editing a wildcard search by hand. This meant that anyone could retrieve all the records on any sort of data set. So how did this happen?

Only USPS can speak on behalf of the dev and test teams, but what is plainly visible is that it could have been prevented with some well thought out functional testing. Specifically, this is a good demonstration why schema validation is not where testing finishes but is the starting point. Verifying that the returned data is really meant to be seen by a certain user is, in our opinion, just common sense. This is especially true as PSD2 comes into play and banks are now exposing personal information.

This also leads to another consideration about test data. You can’t ask your QA teams to investigate all the possible “what if” scenarios, where all they have is an outdated CSV file with some possibly valid inputs. Certainly, fixed input data is often unavoidable, but a testing pattern should always try to include routines that introduce a certain level of controlled randomness. Or, whenever possible, use an API as a data source so that results will naturally acquire a degree of unexpected paths.

Bugs and weaknesses happen; they are unavoidable. Fortunately, there are tools and best practices today that allow you to minimize the extent of their potential damage. For tips on API testing, Jason at API Fortress did a webinar recently specifically on that topic.