C3: Secure Database Access
New Version of the Control Available!
You are looking at the legacy 2018 version of the OWASP Top 10 Proactive Controls. You can find information about the same control within the OWASP Top 10 Proactive Controls 2024 within C3: Validate all Input & Handle Exceptions!
Description
This section describes secure access to all data stores, including both relational databases and NoSQL databases. Some areas to consider:
- Secure queries
- Secure configuration
- Secure authentication
- Secure communication
Secure Queries
SQL Injection occurs when untrusted user input is dynamically added to a SQL query in an insecure manner, often via basic string concatenation. SQL Injection is one of the most dangerous application security risks. SQL Injection is easy to exploit and could lead to the entire database being stolen, wiped, or modified. The application can even be used to run dangerous commands against the operating system hosting your database, thereby giving an attacker a foothold on your network.
In order to mitigate SQL injection, untrusted input should be prevented from being interpreted as part of a SQL command. The best way to do this is with the programming technique known as 'Query Parametrization'. This defense should be applied to SQL, OQL, as well as stored procedure construction.
A good list of query parametrization examples in ASP, ColdFusion, C#, Delphi, .NET, Go, Java, Perl, PHP, PL/SQL, PostgreSQL, Python, R, Ruby and Scheme can be found at https://bobby-tables.com and the OWASP Cheat Sheet on Query Parametrization.
Caution on Query Parametrization
Certain locations in a database query can not be used with parametrization. These locations are different for each database vendor. Be certain to do very careful exact-match validation or manual escaping when confronting database query parameters that cannot be bound to a parametrized query. Also, while the use of parametrized queries largely has a positive impact on performance, certain parametrized queries in specific database implementations will affect performance negatively. Be sure to test queries for performance; especially complex queries with extensive like clause or text searching capabilities.
Secure Configuration
Unfortunately, database management systems do not always ship in a "secure by default" configuration. Care must be taken to ensure that the security controls available from the Database Management System (DBMS) and hosting platform are enabled and properly configured. There are standards, guides, and benchmarks available for most common DBMS.
A quick guidance on providing a secure configuration can be found in the Database Cheat Sheet.
Secure Authentication
All access to the database should be properly authenticated. Authentication to the DBMS should be accomplished in a secure manner. Authentication should take place only over a secure channel. Credentials must be properly secured and available for use.
A quick guidance on providing a secure authentication process can be found in the Database Cheat Sheet.
Secure Communication
Most DBMS support a variety of communications methods (services, APIs, etc) - secure (authenticated, encrypted) and insecure (unauthenticated or unencrypted). It is a good practice to only use the secure communications options per the Protect Data Everywhere control.
A quick guidance on providing a secure communication mean can be found in the Database Cheat Sheet.