SQL injection from concatenated SQL fragments in go-pg ORM clauses

Critical Risk sql-injection
gogolanggo-pgormpostgresqlsql-injection

What it is

SQL injection vulnerability where non-literal variables are concatenated or formatted into SQL strings instead of parameter binding in go-pg ORM operations, potentially allowing attackers to read, modify, or delete database data and escalate privileges.

ℹī¸ Configuration Fix

Configuration changes required - see explanation below.

💡 Explanation

ℹī¸ Configuration Fix

Configuration changes required - see explanation below.

💡 Explanation

Why it happens

Non-literal variables are concatenated into SQL fragments used in go-pg Where, WhereOr, Join, and other clauses.

Root causes

String Concatenation in go-pg Clauses

Non-literal variables are concatenated into SQL fragments used in go-pg Where, WhereOr, Join, and other clauses.

Missing go-pg Parameter Binding

Failing to use go-pg's placeholder system and parameter binding for dynamic values.

Fixes

1

Use go-pg Placeholders and Parameters

Replace string concatenation with go-pg placeholders and pass values as separate arguments.

View implementation 
db.Model(&users).Where("name = ?", userName) instead of Where(fmt.Sprintf("name = '%s'", userName))
2

Use go-pg Safe Query Methods

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

View implementation 
Use WhereGroup, Join with proper parameter binding, avoid string building in SQL fragments
3

Validate Dynamic Input

When building dynamic queries, validate all input values and use allow-lists for field names.

View implementation 
Validate field names against known columns before using in OrderExpr or GroupExpr

Detect This Vulnerability in Your Code

Sourcery automatically identifies sql injection from concatenated sql fragments in go-pg orm clauses and many other security issues in your codebase.

Scan Your Code for Free Explore More Vulnerabilities