Guarding Against SQL Injection at the Database Layer (SQL Server)

Question

Guarding Against SQL Injection at the Database Layer (SQL Server)

Terry Jago

SSCrazy

Points: 2397
More actions
March 2, 2026 at 12:00 am

#4736451

Comments posted to this topic are about the item Guarding Against SQL Injection at the Database Layer (SQL Server)

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply

will 58232 SSC-Addicted Points: 482 More actions · Answer 1

The solution to SQL injection is to place all user identification and security in the database.

Using a combination of table and row level security is possible to define exactly which data the users in any role can select or update. As far as a particular group of users is concerned this defined subset of the database is the database.

So an application can use whatever SQL it likes, including dynamic SQL, without compromising the data or the structure of the database in any way.

Terry Jago SSCrazy Points: 2397 More actions · Answer 2

You’re right, putting proper user identification and security in the database is a strong solution. Using table and row level security properly can lock things down very tightly and, in theory, let the application do what it wants without exposing data or structure.

The difficulty is that a lot of systems in production today were built years ago, when security was not always designed in from the start. Many still use shared SQL accounts with broad permissions, and access control is handled mostly in the application layer.

Moving those systems to granular role-based access and row level security can mean major refactoring. It often involves changes to authentication, permissions, stored procedures, and sometimes the overall architecture. That is the right direction, but it is rarely something that can be done quickly.

I still see SQL injection in the wild quite often, especially in legacy estates. For many organisations, strengthening database-layer security has to happen step by step rather than all at once.

Completely agree with you on the end goal though.

will 58232 SSC-Addicted Points: 482 More actions · Answer 3

Implementing the database level security would open up the database to flexible access independent of applications. This is one of the reasons that we have relational DBMSs to begin with.

This could be done without any impact on existing applications. The applications could follow on, though the first step would be to severely restrict the access rights of the generic login used by each application.

Terry Jago SSCrazy Points: 2397 More actions · Answer 4

You are right however, Restricting database login rights reduces the impact surface of a successful SQL injection attack but does not prevent injection itself. Prevention requires parameterized queries and safe query construction at the application layer. Database-level controls provide defence-in-depth, not primary mitigation.

will 58232 SSC-Addicted Points: 482 More actions · Answer 5

Database level security offers security of the data against SQL injection completely independently of how the database is accessed either through applications or ad-hoc queries. There need be no duplication of the security logic in different applications, substantially reducing errors and the workload of application developers.

The remaining risk of SQL injection is denial of service by, for example, starting a Cartesian product of the largest tables in the database inside a serialisable transaction. Some other methods would be necessary to protect against this, but the data would still be safe.