Stored Procedures vs No Stored Procedures - Security Viewpoint

Question

For a web application database, from a security standpoint only, what are arguments counter to the point for an sp only solution where the app db account ha

Answer 1

In addition to the traditional security separation with stored procedures (EXEC permission on procedures, rely on ownership chaining for data access) stored procedures can be code signed, resulting in very granular and specific access control to any server functionality like linked servers, server scoped management views, controlled access to stored procedures and even data in other databases outside of user ordinary access.

Ordinary requests made in T-SQL batches, no matter how fancy and how many layer upon layers of code generation and ORM are behind it, simply cannot be signed and thus cannot use one of the most specific and powerful access control mechanisms available.

Answer 2

This is one of those areas where conventional wisdom is correct: exposing just the stored procedures gives you more control over security. Giving direct access to tables and views is easier, and there are times you need to do it, but it's going to be less secure.

Answer 3

Well, I guess you really captured the core of the problem yourself: if you don't use stored procedures for all CRUD operations, you have to grant at least a app-specific db user account at least SELECT rights on all tables.

If you want to allow the db account to do even more work, that account might also need other permission, like being able to UPDATE and possibly DELETE on certain tables.

I don't see how a non-stored proc approach would have any security benefits - it does open up the gate just a bit more, the question really is: can you afford to? Can you secure that app-specific DB account enough so it won't compromise your system's overall security?

One possible compromise might be to use views or table access to allow SELECT, but handle everything else (UPDATEs, DELETEs, INSERTs) using stored procs - half secure, half convenient...

As it often is - this is a classic trade-off between convenience (non-sp approach; using an ORM possibly) and security (all SProc approach; probably more cumbersome, but a bit safer).

Marc