# SQL Injection (CWE-89)

User input is concatenated directly into SQL queries, allowing attackers to modify the query logic and access or manipulate data. This is one of the oldest and most dangerous vulnerability classes, responsible for some of the largest data breaches in history.

**Stack:** Go

- Prevalence: Very Common OWASP Top 10 since 2010
- Impact: Critical Data breach, auth bypass, RCE
- Prevention: Well understood Parameterized queries

**OWASP:** Injection (A03:2021-Injection) - #3

## Description

Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. This can be used to alter query logic to bypass security checks, or to insert additional statements that modify the back-end database.

## Prevention

Prevention strategies for SQL Injection based on 1 Shoulder detection rules.

### Go

Use parameterized queries with $1 (PostgreSQL) or ? (MySQL/SQLite) placeholders

## Warning Signs

- [CRITICAL] user input flowing to SQL queries without parameterization

## Consequences

- Read Application Data
- Modify Application Data
- Bypass Protection Mechanism
- Execute Unauthorized Commands

## Mitigations

- Use parameterized queries or prepared statements
- Use stored procedures with parameterized queries
- Escape all user-supplied input using the specific escape routine for your database

## Detection

- Total rules: 7
- Critical: 6
- Languages: go, javascript, typescript, python

## Rules by Language

### Go (1 rules)

- **SQL Injection via Database Queries** [CRITICAL]: Detects user input flowing to SQL queries without parameterization.
  - Remediation: Use parameterized queries with placeholders instead of string concatenation.

```go
rows, err := db.Query("SELECT * FROM users WHERE id = $1", userID)
```

Learn more: https://shoulder.dev/learn/go/cwe-89/sql-injection