Sql Injection in Gorilla Mux with Api Keys

SQL injection occurs when untrusted input is concatenated into SQL queries without proper validation or parameterization. In a Gorilla Mux router, routes often capture variables from the URL path or query parameters, and those values can be directly used to build SQL statements. When API keys are handled as request headers or query parameters and then passed into database operations, they can become an untrusted data source if treated as raw strings. For example, extracting an apiKey from headers and using it to construct a dynamic query such as SELECT * FROM resources WHERE owner_key = '" + apiKey + "' introduces a classic injection vector. An attacker could provide a key like ' OR '1'='1 to alter query logic, bypass ownership checks, or extract sensitive rows.

Gorilla Mux does not sanitize or validate extracted parameters automatically; developers must enforce safe handling. If an API key is also used for rate limiting or tenant identification, injection can lead to privilege escalation across tenants or unauthorized data access. In black-box scanning, middleBrick tests such paths by injecting SQL metacharacters into apiKey and similar inputs to detect whether queries are constructed safely. The presence of parameterized queries or prepared statements is critical; without them, attackers can exploit string concatenation to run arbitrary SQL commands, potentially revealing data via error messages or modifying records.

Additionally, if OpenAPI specs define apiKey parameters as security schemes but runtime handling concatenates them into SQL, the discrepancy between spec intent and implementation becomes a high-risk finding. middleBrick correlates the spec definition of security schemes with runtime behavior to highlight where untrusted inputs reach the database layer. This combination of dynamic routing, manual query assembly, and key-based access logic increases the attack surface, making rigorous input validation and strict use of parameterized queries essential.

Remediation focuses on ensuring that API key values are never directly interpolated into SQL strings. Use prepared statements with parameterized queries so that the database driver treats the key strictly as data, not executable SQL. Below are concrete examples that demonstrate safe patterns for Gorilla Mux handlers.

First, a vulnerable pattern to avoid:

// DO NOT DO THIS: vulnerable to SQL injection
func getResourceHandler(w http.ResponseWriter, r *http.Request) {
    vars := mux.Vars(r)
    apiKey := vars["apiKey"]
    query := "SELECT name, settings FROM resources WHERE api_key = '" + apiKey + "'"
    rows, err := db.Query(query)
    // handle error and rows
}

Correct approach using parameterized queries with database/sql:

// Safe: parameterized query
func getResourceHandler(w http.ResponseWriter, r *http.Request) {
    vars := mux.Vars(r)
    apiKey := vars["apiKey"]
    query := "SELECT name, settings FROM resources WHERE api_key = ?"
    rows, err := db.Query(query, apiKey)
    if err != nil {
        http.Error(w, "Internal error", http.StatusInternalServerError)
        return
    }
    defer rows.Close()
    // process rows
}

If you use PostgreSQL with pgx, use pgx's parameterized queries:

// Safe with pgx
func getResourceHandler(w http.ResponseWriter, r *http.Request) {
    vars := mux.Vars(r)
    apiKey := vars["apiKey"]
    var name string
    var settings json.RawMessage
    err := conn.QueryRow(r.Context(), "SELECT name, settings FROM resources WHERE api_key = $1", apiKey).Scan(&name, &settings)
    if err != nil {
        http.Error(w, "Not found or server error", http.StatusInternalServerError)
        return
    }
    // respond with name and settings
}

When API keys are passed as headers (e.g., Authorization: ApiKey abc123), extract them safely and still use parameters:

// Safe: header-based API key with parameterized query
func apiKeyMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        auth := r.Header.Get("Authorization")
        const prefix = "ApiKey "
        if !strings.HasPrefix(auth, prefix) {
            http.Error(w, "Unauthorized", http.StatusUnauthorized)
            return
        }
        apiKey := strings.TrimPrefix(auth, prefix)
        // Store in context for downstream handlers; do not concatenate into SQL
        ctx := context.WithValue(r.Context(), "apiKey", apiKey)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

func getResourceHandler(w http.ResponseWriter, r *http.Request) {
    apiKey := r.Context().Value("apiKey").(string)
    query := "SELECT name, settings FROM resources WHERE api_key = ?"
    rows, err := db.Query(query, apiKey)
    // safe handling
}

For middleware that validates keys against a database, use parameterized SELECTs to fetch the key metadata without injection risk:

// Safe: validating key existence with parameterized query
func validateApiKey(db *sql.DB, apiKey string) (bool, error) {
    var exists bool
    err := db.QueryRow("SELECT EXISTS(SELECT 1 FROM api_keys WHERE key_value = ?)", apiKey).Scan(&exists)
    return exists, err
}

These patterns ensure that API key values are bound as parameters, preventing SQL injection while preserving the intended access control semantics. Always prefer parameterized queries over string formatting or concatenation when dealing with keys and identifiers.