I have seen some guidance which recommends that you secure a database by layering all data access through stored procedures.
I know that for SQL Server, you can secure t
Because by limiting all access to those stored procs you have established a defined interface to the database, through which all access must occur... Since you will have DENY'd Direct select, insert, update, and delete operations against the tables and views, noone can directly write sql of their own design that does whatever they want to... If you want to limit inserts into the employee table where the employee is assigned to more than three projects to to only those employees that have a score greater than 85 on a proficiency test, then you can write that constraint intoi the SaveEmployee sproc, and have it throw an exception to any client code that attempts to do that...
Sure you COULD do the same thing using client-side code, but using sProcs makes the process easier to design and manage, cause it's all in one place, and ALL applications that attempt to access this database system HAVE to conform to whatever constraints and/or security provisions you define in the SProcs... No rogue developer writing a new separate client app that hits the database can ignore or work-around a constraint or security provision in a SProc if that SProc s the ONLY WAY to insert or update a record...