Fix SQL Injection (Legacy & Modern) in Go Fiber

SQLi in the Go ecosystem isn't dead; it just evolved. Whether you're using the standard 'database/sql' or an ORM like GORM with Fiber, the moment you use fmt.Sprintf to build a query, you've handed the keys to your database to any script kiddie with a browser. Modern SQLi in Fiber apps often hides in 'Raw' queries or dynamic 'ORDER BY' clauses. The fix is absolute: never trust user input, and always use parameterized drivers.

The Vulnerable Pattern

app.Get("/api/v1/user", func(c *fiber.Ctx) error {
    userID := c.Query("id")
    // CRITICAL VULNERABILITY: String concatenation in SQL query
    query := fmt.Sprintf("SELECT username, email FROM users WHERE id = %s", userID)
rows, err := db.Query(query)
if err != nil {
    return c.Status(500).SendString("Database Error")
}
return c.JSON(rows)
})

The Secure Implementation

The vulnerability stems from the database engine being unable to distinguish between the developer's SQL commands and the attacker's data. When you concatenate 'userID', an attacker can input '1 OR 1=1', altering the query logic. Parameterization (using '?' or '$1') sends the query template and the data in separate packets to the database. The database engine pre-compiles the SQL structure, making it impossible for the data payload to be executed as a command. For dynamic column names where parameterization isn't supported, use a strict whitelist of allowed strings.

app.Get("/api/v1/user", func(c *fiber.Ctx) error {
    userID := c.Query("id")
// SECURE: Using placeholder (?) for parameter binding
// The driver handles escaping and ensures userID is treated as data, not code
var user User
err := db.QueryRow("SELECT username, email FROM users WHERE id = ?", userID).Scan(&user.Username, &user.Email)

if err != nil {
    return c.Status(404).SendString("User not found")
}

// If using GORM (Modern approach):
// db.Where("id = ?", userID).First(&user)

return c.JSON(user)
})