Summary

• Do understand the database you use. Does it support stored procedures?
  What is the comment operator? Does it allow the attacker to call extended functionality?

• Do check the input for validity and trustworthiness .

• Do use parameterized queries, also known as prepared statements, placeholders, or parameter binding to build SQL statements.

• Do store the database connection information in a location outside of the application, such as an appropriately protected configuration file or the Windows registry.

• Do not simply strip out bad words. There are often a myriad of variants you will not detect.

• Do not trust input used to build SQL statements.

• Do not use string concatenation to build SQL statements even when calling stored procedures. Stored procedures help, but they dont solve the entire problem.

• Do not use string concatenation to build SQL statements within stored procedures.

• Do not execute untrusted parameters within stored procedures.

• Do not simply double-up single and double quote characters .

• Do not connect to the database as a highly privileged account, such
  as sa or root.

• Do not embed the database login password in the application or connection string.

• Do not store the database configuration information in the web root.

• Consider removing access to all user -defined tables in the database and granting access only through stored procedures. Then build the query using stored procedure and parameterized queries.