Don’t you hate when you go down the path of getting funding for a new project, seeing the project through, and then realizing that you either overlooked something or didn’t think about the law of unintended consequences and ended up with bigger problems as a result? This scenario plays out in IT all the time and, given the work that I do, I see it in Web application security testing quite often. Below is my list of common oversights, bad assumptions, and gotchas when testing websites and Web applications for security vulnerabilities that you need to be on the lookout for:

You forget to notify all parties involved and share contact information that needs to be readily-available in a pinch.

You test (and negatively impact) production when staging or development environment would’ve sufficed.

You fail to test all platforms that are publicly-accessible, especially if testing has never been performed and you know there’s a high probability of uncovering many vulnerabilities. This creates unnecessary exposure of production data – often data that should never be accessible on non-production systems.

You don’t agree upon specific form data for fields such as Name, E-Mail Address, etc. that will be submitted so that it can be identified and removed by developers or DBAs after testing is complete.

You overlook application functionality and unique user roles that really need to be tested.

You assume that everything that needs to be tested will be readily-available when, in fact, it might require a VPN connection, change in firewall rules, or other modification that can throw off your testing schedule.

You don’t get the development team involved and end up mis-timing the testing of the latest codebase that’s being pushed out or the entire application altogether.

You believe that running one Web vulnerability scanner is sufficient to find all flaws. It’s not! They each have their own unique strengths and weaknesses and, in most cases, you have to run multiple scanners to find everything that matters.

You don’t confirm whether exploitation is wanted/allowed. That SQL injection dump of personally-identifiable information will certainly look good on your final report but it might be violating contract terms or, if not properly secured (encrypted, etc.) on your test systems, state or federal laws.

You forget about the importance of notifying the project lead or developers when critical flaws such as SQL injection and weak passwords are uncovered that need immediate attention.

Keep these things in mind whether you’re running basic vulnerability scans, penetration tests, audits, or more in-depth security assessments. Use them as a checklist when scoping your next Web security assessment project. It’ll help ensure that no stone goes unturned and you’re doing what’s best to minimize the impact your testing has on your Web environment and maximize the value it brings to the business.