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 it that hacking is less Hackers and more 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?
We can’t speak on behalf of the dev and test teams at the USPS, but we can tell you this 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 commonsense. 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. We can’t ask our QA team to investigate all the possible “what if” scenarios, where all we provide 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. Just a couple weeks ago our Solution Engineer Jason did a webinar specifically about that. Our blog also has a lot of information on best practices.