SQL injection from non-literal variables in go-pg SQL query

Critical Risk sql-injection
gogolanggo-pgpostgresqlsql-injectionstring-concatenation

What it is

SQL injection vulnerability where the SQL is built with string concatenation or fmt.Sprintf, inserting variables directly instead of using placeholders and bound parameters, potentially allowing attackers to read or modify data, run arbitrary SQL, and compromise database integrity through injected SQL syntax.

ℹī¸ Configuration Fix

Configuration changes required - see explanation below.

💡 Explanation

ℹī¸ Configuration Fix

Configuration changes required - see explanation below.

💡 Explanation

Why it happens

Using fmt.Sprintf or string concatenation to build SQL queries with variables in go-pg operations.

Root causes

fmt.Sprintf in SQL Construction

Using fmt.Sprintf or string concatenation to build SQL queries with variables in go-pg operations.

Missing Parameter Binding in go-pg

Failing to use go-pg's parameter binding system with placeholders for dynamic values.

Fixes

1

Use go-pg Parameter Binding

Replace fmt.Sprintf and string concatenation with go-pg placeholders and bound parameters.

View implementation 
db.Query(ctx, "SELECT * FROM users WHERE id = ?", userID) instead of fmt.Sprintf
2

Use go-pg ORM Methods

Leverage go-pg's ORM methods that handle parameter binding automatically.

View implementation 
db.Model(&user).Where("id = ?", userID).Select() for type-safe queries
3

Validate All Input Variables

Implement comprehensive validation for all variables used in SQL construction.

View implementation 
Check data types, validate formats, use allow-lists for field names and operators

Detect This Vulnerability in Your Code

Sourcery automatically identifies sql injection from non-literal variables in go-pg sql query and many other security issues in your codebase.

Scan Your Code for Free Explore More Vulnerabilities