Data access security
SQL injection and least privilege
Security is more than one command.
Understand the concept
Injection occurs when untrusted data becomes executable SQL. Use parameterised statements or safe ORM binding, not interpolated WHERE clauses. Parameter binding does not replace authorisation or business validation. Identifiers such as sort columns must come from fixed allowlists.
Do not grant application accounts sysadmin or db_owner. Assign only required object and operation permissions through roles. Keep credentials out of source control and use secret management with rotation. Encryption in transit and at rest are separate controls; masking is not authorisation. Avoid logging personal information or secrets. These examples inspect permissions without creating logins or changing server security.
Limit the impact of database access.
Treating input validation as a substitute for parameter binding.
One topic. Three levels of depth.
SELECT ORIGINAL_LOGIN() AS LoginName, USER_NAME() AS DatabaseUser;Displays connection identity context.
This page does not execute SQL. Practise in the downloadable SqlStudioLab using SSMS. Before rerunning temporary-table examples, remove only the relevant #table. Views, procedures and functions create persistent lab objects; never use a production connection.
Try it yourself first.
List your existing permissions on SalesOrder.
Show the solution and explanation
SELECT permission_name FROM sys.fn_my_permissions(N'lab.SalesOrder', N'OBJECT');The permission list is a starting point, not a complete security audit.