Sql Injection in Echo Go with Bearer Tokens

SQL injection occurs when untrusted input is concatenated into SQL queries without proper parameterization. In Go services built with the Echo framework, this often happens when developers build queries using string concatenation or interpolation even when the request carries a Bearer token for authentication. The presence of a Bearer token does not protect against SQL injection; if the API uses the token only for authorization (e.g., validating identity or scopes) but builds SQL dynamically using request parameters, attackers can still manipulate query structure.

Consider an Echo handler that retrieves a user_id from query parameters or a path variable and uses it directly in a SQL string. Even though a Bearer token identifies the caller, the SQL statement is constructed without placeholders, enabling injection. For example, extracting a user_id from the URL and concatenating it into a query allows an attacker to alter the query logic. The Bearer token might correctly identify an admin, but the SQL logic can be bypassed or data exfiltrated if the query is malformed by injected SQL fragments.

Insecure patterns also appear when developers mistakenly treat the Bearer token as a mechanism that implicitly secures data access boundaries. Authorization and input validation are distinct concerns: a valid token does not imply that input values are safe for SQL. Attackers can supply crafted parameters such as user_id=1 OR 1=1 to manipulate WHERE clauses, or use comment sequences to truncate intended query parts. This exposes data or enables privilege escalation regardless of token validity. The combination of Echo routing, Bearer-based authentication, and dynamic SQL thus creates a scenario where SQL injection remains possible if query construction does not use parameterized statements.

Real-world examples include queries built with string concatenation or formatting functions that incorporate user-controlled data. For instance, extracting a filter value from the request and inserting it directly into the SQL text defeats the safeguards that parameterized queries provide. Even when using database drivers that support prepared statements, failing to use placeholders re-introduces the risk. The presence of a Bearer token in the Authorization header is insufficient to prevent injection; the application must ensure that all SQL composition uses placeholders and strictly separates data from commands.

To detect such issues, scanning with middleBrick against an API that uses Bearer tokens and dynamic SQL surfaces these flaws by correlating authentication patterns with query construction behavior. The tool evaluates whether endpoints that require authorization still rely on unsafe string building, highlighting where injection vectors exist despite the presence of tokens. This underscores the importance of consistent use of parameterized queries across all endpoints, independent of authentication mechanisms.

Remediation centers on using parameterized queries and strict input validation, independent of Bearer token handling. Always use placeholders provided by your database driver and pass user-controlled values as parameters. Below are secure code examples for Echo Go that demonstrate these practices.

Secure query with placeholders

Use db.QueryRow with placeholders and explicit parameter binding. This ensures user input is never interpreted as SQL code.

// Correct: parameterized query with Echo context
func getUserProfile(c echo.Context) error {
    userID := c.Param("id") // or from query: c.QueryParam("user_id")
    // Validate and sanitize userID if needed (e.g., ensure it's numeric)
    var profile Profile
    err := db.QueryRow("SELECT id, name, email FROM profiles WHERE id = $1", userID).Scan(&profile.ID, &profile.Name, &profile.Email)
    if err != nil {
        return echo.NewHTTPError(http.StatusInternalServerError, "unable to fetch profile")
    }
    return c.JSON(http.StatusOK, profile)
}

Using named parameters with sql.Named

For clarity and to avoid positional mistakes, use named parameters when supported by your driver.

// Example with sql.Named (driver-specific support may vary)
stmt, err := db.Prepare("SELECT id, name FROM users WHERE id = :user_id AND status = :status")
if err != nil {
    return echo.NewHTTPError(http.StatusInternalServerError, "prepare failed")
}
defer stmt.Close()

var user User
err = stmt.QueryRow(sql.Named("user_id", userID), sql.Named("status", "active")).Scan(&user.ID, &user.Name)
if err != nil {
    return echo.NewHTTPError(http.StatusNotFound, "user not found")
}
return c.JSON(http.StatusOK, user)

Validating and sanitizing input before use

Even with placeholders, validate input types and formats. For identifiers, ensure they conform to expected patterns (e.g., numeric IDs) before using them in queries.

// Validate numeric ID
idStr := c.Param("id")
id, err := strconv.Atoi(idStr)
if err != nil {
    return echo.NewHTTPError(http.StatusBadRequest, "invalid user id")
}
// Now safe to use 'id' as integer in parameterized query

Middleware for Bearer validation without affecting SQL safety

Use Echo middleware to validate tokens, but keep SQL construction safe and separate. The middleware ensures requests are authenticated, while parameterized queries ensure SQL safety.

func AuthMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        auth := c.Request().Header.Get("Authorization")
        if auth == "" {
            return echo.NewHTTPError(http.StatusUnauthorized, "missing authorization")
        }
        // Example: validate Bearer token format
        if !strings.HasPrefix(auth, "Bearer ") {
            return echo.NewHTTPError(http.StatusUnauthorized, "invalid authorization type")
        }
        token := strings.TrimPrefix(auth, "Bearer ")
        // Perform token validation (e.g., JWT verification, introspection)
        if !isValidToken(token) {
            return echo.NewHTTPError(http.StatusUnauthorized, "invalid token")
        }
        return next(c)
    }
}

By combining proper middleware for Bearer validation with parameterized SQL, you eliminate SQL injection risks while maintaining robust authentication. middleBrick can verify that these practices are consistently applied across endpoints by scanning for unsafe query construction patterns alongside authentication configurations.