Explanation/Reference:
Explanation:
A login would also be needed.
Note:
One method of creating multiple lines of defense around your database is to implement all data access
using stored procedures or user-defined functions. You revoke or deny all permissions to underlying
objects, such as tables, and grant EXECUTE permissions on stored procedures. This effectively creates a
security perimeter around your data and database objects.
Best Practices
Simply writing stored procedures isn't enough to adequately secure your application. You should also
consider the following potential security holes.
Grant EXECUTE permissions on the stored procedures for database roles you want to be able to

access the data.
Revoke or deny all permissions to the underlying tables for all roles and users in the database,

including the public role. All users inherit permissions from public. Therefore denying permissions to
public means that only owners and sysadmin members have access; all other users will be unable to
inherit permissions from membership in other roles.
Do not add users or roles to the sysadmin or db_owner roles. System administrators and database

owners can access all database objects.
References: https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/managing-permissions-
with-stored-procedures-in-sql-server