Sql Injection in Echo Go with Basic Auth

Using SQL queries with string concatenation or interpolation in an Echo Go handler that also uses HTTP Basic Authentication can expose the application to SQL Injection even when authentication is enforced. Basic Auth provides a transport-layer identity check, but it does not sanitize or validate how the extracted username and password are used downstream. If the handler builds SQL statements by concatenating user-controlled path parameters, query parameters, or request body fields with credentials or other data, an attacker can supply crafted input that alters the structure of the SQL command.

For example, consider an endpoint like /users/:username protected by Basic Auth, where the handler uses the username path parameter directly in a SQL query. An authenticated request with GET /users/validuser might execute normally, but an attacker can send GET /users/validuser%20OR%20%271%27=%271 with valid credentials. If the query is built via string concatenation, the additional clause can bypass intended filters or extract data. This becomes more severe if the Basic Auth credentials themselves are reflected or used to select a database or schema name without proper validation.

Real-world attack patterns mirror common OWASP API Top 10 and CWE-89 scenarios. For instance, an attacker may attempt classic techniques such as UNION-based extraction, boolean-based blind injection, or time-delay payloads to infer data or escalate issues depending on the underlying database. Even when authentication is correctly implemented, SQL Injection can lead to unauthorized data access, data tampering, or in some configurations, command execution depending on the database and its permissions. The combination of Basic Auth and SQL constructs that do not strictly separate code from data increases risk because developers may mistakenly assume that authenticated requests are inherently safe.

Input validation and type handling are critical in this context. Echo Go does not automatically parameterize queries; it is the developer’s responsibility to use prepared statements or query builders. If user input is concatenated into SQL strings, attackers can inject payloads such as ' OR 1=1 -- regardless of the presence of Basic Auth. The scanner’s checks for Input Validation and Authentication are designed to detect such patterns, highlighting where credentials flow into SQL logic without safe separation.

To secure Echo Go handlers that use Basic Auth, always separate SQL logic from identity data. Use parameterized queries or prepared statements so that user input and credentials are never interpreted as executable SQL. Avoid constructing SQL strings via concatenation or interpolation, even for trusted metadata such as usernames extracted from the auth header.

Below are concrete, working examples demonstrating insecure and secure patterns.

Insecure Example

package main

import (
    "github.com/labstack/echo/v4"
    "net/http"
    "database/sql"
    _ "github.com/lib/pq"
)

func getUserInsecure(c echo.Context) error {
    user := c.Param("username")
    // Basic Auth extraction
    userAuth, passAuth, _ := c.Request().BasicAuth()

    db, _ := sql.Open("postgres", "connection_string")
    // UNSAFE: string concatenation
    query := "SELECT id, email FROM users WHERE username = '" + user + "' AND api_key = (SELECT api_key FROM api_keys WHERE user_name = '" + userAuth + "')"
    row := db.QueryRow(query)
    var id int
    var email string
    row.Scan(&id, &email)
    return c.JSON(http.StatusOK, map[string]string{"id": string(id), "email": email})
}

Secure Example with Parameterized Queries

package main

import (
    "github.com/labstack/echo/v4"
    "net/http"
    "database/sql"
    _ "github.com/lib/pq"
)

func getUserSecure(c echo.Context) error {
    user := c.Param("username")
    userAuth, passAuth, _ := c.Request().BasicAuth()

    db, _ := sql.Open("postgres", "connection_string")
    // SAFE: parameterized query
    query := "SELECT id, email FROM users WHERE username = $1 AND api_key = (SELECT api_key FROM api_keys WHERE user_name = $2)"
    row := db.QueryRow(query, user, userAuth)
    var id int
    var email string
    err := row.Scan(&id, &email)
    if err != nil {
        return c.JSON(http.StatusUnauthorized, map[string]string{"error": "invalid credentials"})
    }
    return c.JSON(http.StatusOK, map[string]string{"id": string(id), "email": email})
}

Additional remediation steps include validating the format of usernames and passwords before use, applying least-privilege database roles, and avoiding reflecting authentication headers in SQL responses. When integrating with CI/CD, the GitHub Action can enforce that endpoints using Basic Auth and dynamic SQL are flagged during scans. The dashboard and CLI provide per-category breakdowns for Authentication and Input Validation to guide fixes, while the MCP Server allows developers to scan API contracts directly from their IDEs to catch risky patterns early.