Networking/infrastructure specialists often have a very different view to developers when it comes to security. To be quite frank, the network guys have a very good track record these days (setting up firewalls, locking down servers etc.). The developers, being relatively new to the game, are having to play catch up at a time when many malicious users have discovered the vulnerabilities within web application code (such as SQL injection, cross-site scripting).

It's difficult for developers because there are very few tools or standard configurations that can lock down the application. A developer has to ensure that each function written has the necessary layers of security. For instance, has the input been validated? Is the database being accessed securely via stored procedures when adding the data to the database? Has the user been authenticated somewhere on the web page?

The two points of view (infrastructure specialist and developer) sometimes lead to conflict due to misunderstanding.

A case in point is the use of service accounts. The infrastructure specialist is often, but not always, keen for the logged on user to be identified and authorised by the operating system in all components of the application, by flowing the identity. This can be achieved via kerberos, or simply re-supplying cached credentials to re-authenticate (IIS and its use of NTLM is a good example of this).

The developer sees this quite differently. By flowing the identity to the database, a new security context is used each time. This means that connection pooling (several instances using one database connection, that is retained between batches) is lost, and so performance grinds to a snail's pace very quickly. Also, if one is authenticating and authorising the caller at the database, then that user has direct rights to the database, and can access it without going through the application.

This is why internet facing web sites generally use an application service account. The web server authenticates the user. The web application then uses that identity for checking whether the user can access specific functionality. However, it does not run under the context of that user - it functions under contect of the service account. Only that service account is granted access to the database.

Although this improves performance and prevents users accessing the database directly, there are certain vulnerabilities that have to be controlled. Firstly, this service account has very high levels of access to the database. Compromise of the application can give a lot of potential pwoer to a malicious user. To control this, it's important that secure coding practices are used. Also, tools such as Code Access Security, which restrict what each component of the application can do, mitigate the potential damage. As well as this, the database access should be locked down as much as possible. Never give service accounts dbo or sysadmin privilege. It's always best to give execute permission to stored procedures only.

Secondly, accounting and auditing is reduced. The operating system will log that every operation was performed by the service account. This is where a lot of 'plumbing' has to be coded. Usernames have to be passed to stored procedures, history tables have to be created, database columns with the name 'created by' are added to almost all tables. This can, and usually is, tightly managed.

Architecture guides, such as the ones produced by SUN and Microsoft, give a good overview of the risks, architectural patterns, and implementations that will satisfy security requirements:
http://msdn.microsoft.com/en-us/library/aa302415.aspx
http://www.sun.com/security/index.jsp