The importance of building secure Web applications is rising daily. CEOs are falling all over themselves to assure customers (and Wall Street) that appropriate measures are being taken to prevent unauthorized access to confidential data. The cost of a security breach can be mind-boggling. Legal fees, FTC penalties, and government audits alone can reach into the tens of millions. Add to that brand damage and customer loss for some truly frightening numbers.

Raise the Defenses
To the typical overworked developer application security is yet another requirement in a long list of requirements. Besides, how many developers studied application security at school or are well versed in the latest defensive techniques? For years developers have focused on writing functional, good performing code in a timely manner. After all, that's what is important in most employee performance reviews. Isn't security a problem for the operations team?

Not anymore. Although operations may do everything possible to secure the network and operating system, their efforts will have little impact if the Web application is vulnerable to attacks such as cross-site scripting, SQL injection, cookie poisoning, hidden field manipulation, and so on. Traditional firewalls can be ineffective against HTTP-carried attacks. The application attacker uses valid HTTP requests over well-known ports so network firewalls will allow the attack traffic, by design, because it is good traffic when viewed at the network layer.

What is bad is not the HTTP request itself but the data contained within the request. Often this harmful data is user input that is specially formatted or organized to change the behavior of your application. Application attacks can allow unrestricted access to databases, execute arbitrary system commands, or alter Website content. Proper application security prevents the user from altering the behavior of your application. Hardening the application is a task best addressed as early in the development process as possible.

Test Early, Fix Easily
Finding and resolving security issues on an application already in production is prohibitively expensive. Costs escalate dramatically the longer application errors go undiscovered. According to a 2002 NIST study, when a design error is found in GA, the expense is 30 times what it would have cost to fix the error during the design phase (see table 1). This is just the application teams cost of fixing the error. Other costs such as lost market share, reputation or customer satisfaction must still be factored in.

Table 1: Relative costs based on time lapse between error creation and discovery

	Found in Design	Found in Coding	Found in Integration	Found in Beta	Found in GA
Design Errors	1x	5x	10x	15x	30x
Coding Errors		1x	10x	20x	30x
Integration Errors			1x	10x	20x

(Source: "The Economic Impacts of Inadequate Infrastructure for Software Testing", National Institute of Standards & Technology, May 2002)

Testing Web application security early in the SDLC lowers costs dramatically. The question is how to find and secure vulnerabilities without bringing development to a grinding halt. Many organizations have security professionals on staff to assess application security prior to deployment. These individuals are swamped with work as they must painstakingly assess application vulnerabilities in a constantly changing landscape.

A better approach is empowering developers to conduct security assessments early in (and ideally throughout) the development process. This change would allow security analysts to focus more time and attention on the most at-risk applications, or those that pose the greatest risk to the organization (typically 20 percent of the applications present 80 percent of the risk). By the time an application reaches the security analyst, its major security issues should have already been addressed by the developers responsible for building the application.