views:

33

answers:

1

In my organization, we are just beginning to use the Entity Framework for some applications. In the past, we have pushed developers to utilize stored procedures for all database access. In addition to helping with SQL injection, we tried to grant logins access to stored procedures only to keep security relatively tight.

Although inserting, updating, and deleting are easily done through stored procedures in the EF, it appears to be difficult to use stored procedures to query data with EF. However, using LINQ or Entity SQL and allowing EF to create the queries means giving a user read access to the entire database.

How have others handled this dilemma?

+2  A: 

What kind of data protection are you trying to apply?

With EF, you can write a unit testable business logic layer that will handle many more authorisation scenarios than you can do at the database layer (although I can see how multiple layers of security makes you feel safer):

  • Querying AD (is this user the manager of that user?)
  • Calling web services
  • Checking other environmental contexts

If your circumstances mean you're not ready to think of the database as a store for data rather than a security & business logic layer, then maybe EF isn't right for your project.

P.S. EF will protect you from SQL injection.

Rob Fonseca-Ensor
Quite right. After reviewing some of the security practices I was using for reading data from the database, I determined they were not providing any *true* security.
NYSystemsAnalyst