Conclusion

There are three layers of security wrapped around ASP.NET applications: the IIS layer, the ASP.NET worker process layer, and the application layer. As a developer, you can configure parameters in the first two levels, but you are totally responsible for planning and implementing the third one. Forms authentication is the most reasonable approach to protecting pages from unauthorized access in an Internet exposed application. The most reasonable approach for an intranet application is integrated Windows authentication. Although it's not perfect, Forms authentication is broadly used because it is simple to understand and functional. In ASP.NET 2.0, Forms authentication is partnered with the membership API.

The membership API doesn't change the way in which Forms authentication works, it simply adds new and powerful tools for developers. If you're writing a new ASP.NET 2.0 application, there's no reason for not implementing authentication through the membership API and its auxiliary classes and server controls. If you're migrating an existing application, you should try to embrace the newest API by refactoring your code to make it fully reusable.

Is this enough to claim that an ASP.NET application is secure? Unfortunately not. Secure software requires knowledgeable IT personnel, but no software can ever be considered secure if the network is not at least as secure. Likewise, secure software requires knowledgeable developers, because proper administration is useless and ineffective when the code lays itself open to malicious and injurious attacks. Administration is and remains the primary bedrock of security; however, even a wise and restrictive policy can't do much if developers and architects build inherently insecure code.

To achieve security for any piece of software exposed over the Web, you must enforce network and application security. Network threats to guard against include denial of service (DoS), spoofing, and eavesdropping. Bad effects of these attacks include theft of passwords and other critical data, request floods, and an undesired understanding of internal network topologies by potential attackers. Examples of threats aimed at the application include the notorious SQL injection threat and cross-site scripting (XSS). As an ASP.NET developer, you should apply at least one key rule all the time: don't trust user input.