Crlf Injection in Gin with Bearer Tokens

Crlf Injection occurs when user-supplied data containing carriage return (CR, \r) and line feed (\n) characters is reflected into HTTP headers without sanitization. In the Gin web framework, this commonly arises when developers construct HTTP response headers using values from query parameters, headers, or cookies. When Bearer Tokens are handled in Gin—typically via the Authorization header—improper handling of token values or related headers can introduce Crlf Injection if token-like data is later echoed into other headers.

For example, consider an endpoint that forwards or logs an Authorization header value by directly setting it into a custom header. If an attacker provides a token containing \r\n, they can inject additional headers such as Set-Cookie or X-Content-Type-Options, which may bypass intended security policies. The Gin router does not inherently sanitize header values; it is the developer’s responsibility to validate and sanitize any data used in header construction. Because Bearer Tokens are often base64-like strings, they rarely contain CR or LF, but if a token is extracted from a header and then reused in another context (such as a custom header, log entry, or redirect), the presence of injected line breaks can alter the message body or trigger header splitting.

Real-world impact includes HTTP response splitting, cache poisoning, or open redirects. An attacker might supply a token value like abc123\r\nSet-Cookie: session=attacker, causing the server to append an extra Set-Cookie header if the value is written unsanitized. While the Authorization header itself is parsed by Gin before reaching application code, downstream misuse of extracted token data—such as copying it into a custom header for observability or debugging—creates the injection window. The 12 security checks in middleBrick, including Input Validation and Header/Property Authorization, are designed to detect such header manipulation risks in unauthenticated scans, highlighting places where user-controlled data reaches sensitive control points.

Additionally, if an API specification (OpenAPI 2.0, 3.0, or 3.1) defines security schemes using Bearer format but does not enforce strict header value constraints, runtime findings may reveal mismatches between declared and actual behavior. Tools like middleBrick resolve $ref definitions and cross-reference them with runtime inputs, identifying whether injected line breaks could traverse from headers into response construction. This is especially relevant when token values are logged verbatim or used to construct Location headers in redirects, where a single injected CR/LF can change the semantics of the HTTP transaction.

To remediate Crlf Injection in Gin when working with Bearer Tokens, ensure that any user-controlled data used in headers is strictly validated and sanitized. Do not directly copy header values into other headers or response locations. Instead, treat Authorization header content as opaque and avoid echoing it. Use explicit allowlists for acceptable token characters and reject any input containing control characters.

Below is a secure Gin handler example that extracts a Bearer token safely and avoids header injection:

package main

import (
    "net/http"
    "regexp"
    "strings"

    "github.com/gin-gonic/gin"
)

// Bearer token pattern: letters, digits, hyphens, underscores, periods, and base64 chars
var bearerTokenRegex = regexp.MustCompile(`^[A-Za-z0-9\-._~+/=]+$`)

func safeAuthHandler(c *gin.Context) {
    auth := c.GetHeader("Authorization")
    if auth == "" {
        c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "missing authorization header"})
        return
    }

    // Ensure the Authorization header follows Bearer format
    if !strings.HasPrefix(auth, "Bearer ") {
        c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "invalid authorization type"})
        return
    }

    token := strings.TrimPrefix(auth, "Bearer ")
    if !bearerTokenRegex.MatchString(token) {
        c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "invalid token characters"})
        return
    }

    // Do NOT set token into arbitrary headers; if needed for internal use, use structured logging without header injection
    c.JSON(http.StatusOK, gin.H{"status": "authorized"})
}

In this example, the token is extracted and validated against a strict regex that excludes CR (\r) and LF (\n) characters. By rejecting any token containing control characters or unexpected formats, the handler prevents injection attempts. Avoid using c.Set() or c.Header() with raw Authorization values, and never construct headers by concatenating user input.

For API specifications, ensure that security scheme definitions clearly document expected token formats and that runtime validation aligns with these definitions. The middleBrick CLI can be used to scan your Gin endpoints with the command middlebrick scan <url>, producing a per-category breakdown that flags Input Validation and Header/Property Authorization issues. Teams on the Pro plan gain continuous monitoring and GitHub Action integration, which can fail builds if a scan detects header injection risks, helping prevent regressions before deployment.