Preventing SQL Injection at the Database

SQL injection vulnerabilities are common out in the real world. We spend a lot of time and effort looking for SQL injection vulnerabilities in application code, a good and necessary practice. Application security, however, must be considered at every layer of the system. In fact, by using a good database and data access layer design, we can help eliminate the possibility of a SQL injection vulnerability.

True, the topic of database and data access layer design is expansive, including the use of service accounts and row-level authorization. But for now, here’s a simple way using two small requirements to make sure that the database itself is doing its part to facilitate a secure database and data access layer and to protect against SQL injection attacks.

These two requirements are:

1) All data access should occur via parameterized stored procedures.

2) Users should be limited to CONNECT and EXECUTE privileges.

By ensuring that all data access is via stored procedures, we can enforce the practice of parameterizing variables, thus eliminating the possibility of random SQL statements getting to our database. Of course, you must also make sure that your stored procedures are properly written and do not include any insecure practices such as using sp_executesql.

By limiting users to CONNECT and EXECUTE privileges, we can limit the possibility of users executing random SQL statements. If they try to SELECT anything, for example, it will fail.