[The following is excerpted from "Strategies for Improving Web Application Security," a new report posted this week on Dark Reading's Application Security Tech Center.]

Web applications are the most frequent targets for online hackers -- partly because they are your enterprise's most visible points of entry and partly because they are notoriously fraught with vulnerabilities. At the same time, most enterprises must maintain a Web presence in order to do business, so there's little choice about facing the risk.

Being proactive about Web application security should be a top IT priority: When a Web application is taken out, money is lost. And for big-name businesses at least, it's not the financial loss that hurts the most; it's the loss to reputation. Protracted outages of an important Web application will draw the ire of customers and the CEO alike. And fair or unfair, it doesn't matter whether an attack was preventable -- IT will get the blame.

When CIOs and CFOs hear the word "security," they generally prepare themselves for sticker shock. However, you don't need to spend a ton of money to harden your Web applications. Winning the battle requires a combination of security-related best practices and tools.

Placing your Web servers in a DMZ won't technically make your Web applications or website more secure, but the practice will certainly help protect the rest of your infrastructure from attack if a Web server is successfully compromised.

If you host your own website or Web application, then your perimeter defenses are getting scanned all day long for vulnerabilities.

You can't stop an attacker from probing your perimeter for open services, but you can certainly make it harder for an attacker to inflict further damage should he or she successfully compromise one of your Web servers. The whole point of placing externally facing Web servers in a DMZ is to box in an attacker and limit the damage that can be done should a server be compromised.

One of the quickest and easiest ways to reduce the attack surface of your Web apps is to make sure you're dropping all nonessential ports inbound to your Web server farm.

If you're exposing a Web application, there's no reason to allow RDP to your Web server; there's no reason for allowing ICMP. Exposing additional TCP/UDP services to a Web server may be required for testing or troubleshooting, but, beyond that, there's no reason to allow any incoming connection to your Web server other than TCP 80 and/or 443. As a best practice, inspect your firewall rule base periodically for irregularities, especially if you have several people managing your corporate firewalls.

Web application firewalls aren't typically necessary if you're trying to protect an internal Web application, but for large organizations that have externally facing Web apps and a lot of money to lose if they go down, a WAF is highly recommended.

Sure, a properly and carefully developed app wouldn't likely require WAF-level protection. But we know that Web developers can sometimes be their own worst enemies by not validating user-supplied input, and there's nothing Web developers can do from a coding perspective to protect a Web application from a sustained denial-of-service attack.

To get more tips and tricks for protecting Web applications -- and processes for implementing them -- download the free report.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.