Any data entered by a customer or visitor, especially data that is persisted to a database, should be considered “dirty”. No offence visitors!
Assume every interaction with your website is an attempt to hack it.
When you add some new functionality involving customer data entry:
- Document what functionality was added.
- Sanitise the data from the customer.
- Test that they cannot cause harm.
Document the threat!
This is a very important, but often overlooked, step.
For any project you should maintain a ‘customer data entry’ document. Add the scenario and a brief overview of what will happen to the data, where else it will appear (eg. customer account, checkout, admin panel, etc.) and what steps have been taken to sanitise it (see below).
This documentation will form a section of your QA Testing scenarios.
Furthermore, should you involve a Penetration Testing team, they will shake your hand for being so thoughtful as to point out the potential vulnerabilities you have introduced.
It’s better they find any issues than the customers!
Sanitise the Data
It is a good idea to name any variables in an obvious way to highlight they contain dirty customer data. For example, I like to use the prefix
$dirtyName = $request->getFormData('name');
$name = $securityHelper->sanitise($dirtyName);
Test with some Bad Data
Finally add a unit, integration or functional test with some nasty script data that you would want to be protected against, ideally in a re-usable format since you’ll want to run this same test across various areas of your project.
Your test should automate the checking that dirty data does not go into the database.