Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')


SQL Injection represents a severe vulnerability that can culminate in the compromise of data or entire systems. When SQL query strings are crafted dynamically based on user inputs, there's potential for malicious users to manipulate the logic of the SQL statement. Such tampering could provide adversaries unauthorized access to sensitive data or even allow them to execute system-level operations or code.


✅ Use Parameterized Queries

Always opt for parameterized queries over dynamically generated SQL queries to prevent SQL injection.

rows, err := db.Query("SELECT * FROM users WHERE userName = ?", userName)
if err != nil {
return nil, err
defer rows.Close()
for rows.Next() {
// ... process rows

✅ Avoid Direct User Input in Dynamic Queries

If there's an absolute need to formulate dynamic queries, ensure that direct user input is never utilized. Instead, leverage a map or dictionary containing valid values and determine them through a user-provided key.

For instance, certain database drivers do not support parameterized queries for operators like > or <. Instead of directly using user-input values, allow users to provide substitutes like gt for > and lt for <. Subsequently, use these alphabetical inputs to retrieve the actual operators for your query. Implement a similar approach for queries requiring non-parameterizable column or table names.


Associated CWE

OWASP Top 10


To skip this rule during a scan, use the following flag

bearer scan /path/to/your-project/ --skip-rule=go_gosec_sql_concat_sqli

To run only this rule during a scan, use the following flag

bearer scan /path/to/your-project/ --only-rule=go_gosec_sql_concat_sqli

Ready to take the next step? Learn more about Bearer Cloud.