If somebody can login to Application Server & read configuration files, he can delete website as well (worst scenario).
SQL Server Logins are manageable for Web Applications. Few logins (Logical Grouping based on roles) can manage overall database operation for the Web Users. I don’t find it logical to create 1000 Users / Logins in database until I have explicit Audit Requirements to track each user’s activity.
Sure, the problem is bigger if they can get to the config files, but why have the DB Exposed at all?
You don't have to create a login for every user to use Windows Authentication if you use the first option I mention. It is still basically using an application login, it is just using an AD account for the app pool instead of SQL Authentication.
You can also use AD groups to limit the # of logins you create. Then login is managed through AD groups and, if you are using least privileges, that works fine.
Don't let the good be the enemy of the best. -- Paul Fleming
At best you can say that one job may be more secure than another, but total job security is an illusion. -- Rod at work
Check out these links on how to get faster and more accurate answers: Forum Etiquette: How to post data/code on a forum to get the best helpNeed an Answer? Actually, No ... You Need a QuestionHow to Post Performance ProblemsCrosstabs and Pivots or How to turn rows into columns Part 1Crosstabs and Pivots or How to turn rows into columns Part 2