When testing the security of a Web application, do you think it is better to do a penetration test, or to review the code of the app? I only have the budget for one or the other.
Ask the Expert!
SearchSecurity.com expert Michael Cobb is standing by to answer your questions about enterprise application security and platform security. Submit your question via email. (All questions are anonymous.)
Ideally, of course, you would have the budget to carry out both an application code review and a penetration test, as completing both provides the best multi-layered defense. However, employing a full-time staff with the necessary skills in both fields is beyond the budget of most businesses, and using third-party specialists can be expensive on larger projects. Therefore, if my budget forced me to make a choice between the two for the purpose of Web application security testing, I would opt for a penetration test.
This isn't because I don't think application code reviews are worthwhile. Solving problems at the code level can reduce the number of security-related design and coding defects that make it through to the release version, thus improving the overall security of the application dramatically. Also, a code review can uncover application logic flaws, which is something a Web application firewall can't protect against. With access to the source code, reviewers can examine exactly how data flows through the application and how specific types of data, such as credit card numbers and personal data, are processed and protected; for example, when and how sensitive data is encrypted and decrypted. The main disadvantage of a code review is that it's a protracted and expensive way to find security flaws in all but the most basic Web applications.
Those reviewing the code need to have extensive application development experience and security expertise, but cannot be the same people that wrote the original code. Having such a dedicated team is only economical for large enterprises that are constantly developing their own applications. Automated application source code analyzer tools can shorten the time to review large, complex applications. And while they can identify the issues the analysts need to concentrate on, they can't test adherence to security policy or identify backdoors in an application in the same way as a manual code review.
My preference for a penetration test is based on its coverage of not only the application, but also the environment in which it operates. It can test the resilience of both the network and the application, as well as the controls and processes around them. A complete pen test can include physical security controls, employees' resilience to social engineering, wireless connections and any other possible application access methods. While such a test will incur the costs of an experienced penetration team, it provides a holistic evaluation of the actual live environment in which an application resides, which is something a code review does not come close to doing.
Whether you opt for a code review or a pen test, they are only worthwhile if you correct the vulnerabilities found by the process. Both checks only provide a snapshot of an application's security at a point in time. Any time the application is modified, a code review of the changes should be completed and any significant infrastructure or application changes should prompt another pen test to ensure that controls that are assumed to be in place are still working effectively. In light of the findings from a code review or penetration test, placing a firewall in front of an application might be less costly and less disruptive than rewriting an application.