Server Side Template Injection in Gin with Bearer Tokens

Server Side Template Injection (SSTI) occurs when an attacker can inject template directives that are later evaluated by a server-side templating engine. In the Go ecosystem, the Gin framework does not include a built-in template engine, but applications commonly integrate third-party engines such as html/template, text/template, or third-party libraries like gomponents. When user-controlled data flows into these templates without proper escaping or sandboxing, SSTI becomes possible. The presence of Bearer Tokens in Gin-based APIs influences the attack surface primarily through authorization handling and logging practices.

Consider a Gin handler that extracts a Bearer Token from the Authorization header and passes it to a template for rendering user context or debugging output. If the token value is directly interpolated into the template (for example, using .Token), and the template engine evaluates or re-processes that value, an attacker who can influence the token format may achieve template injection. Bearer Tokens are often long strings containing characters that, while typically benign, could contain sequences that match template syntax in certain engines or be logged in a way that enables secondary injection through log-based template rendering.

Another scenario involves OpenAPI/Swagger spec analysis combined with runtime findings. If an API exposes an endpoint that echoes the Authorization header or includes token metadata in responses that are later processed by a template (e.g., admin dashboards), an attacker may probe token formats to discover injection vectors. middleBrick’s OpenAPI/Swagger spec analysis with full $ref resolution can cross-reference spec definitions with runtime findings to identify places where token-derived data enters template contexts. The 12 security checks run in parallel, including Input Validation and Property Authorization, can surface cases where untrusted data derived from Bearer Tokens reaches a template engine without sufficient sanitization.

Real-world attack patterns mirror classic SSTI techniques: injecting template actions, functions, or control structures via crafted token values. For instance, if a token is used in a Go template like {{ .Token | safeHTML }}, and the token contains Go template syntax (e.g., {{define "attack"}}...{{end}}), a vulnerable configuration could allow arbitrary template code execution. This is especially risky when combined with verbose logging or debug endpoints that render token values using templates, effectively turning the Bearer Token into a vector for server-side code execution or information disclosure.

middleBrick tests these scenarios by analyzing both static specifications and runtime behavior without credentials. It checks whether data derived from authorization headers flows into template contexts and whether escaping or sandboxing controls are applied. The scanner’s Input Validation and Data Exposure checks highlight cases where token-derived data reaches unsafe rendering paths, providing prioritized findings with severity ratings and remediation guidance mapped to frameworks such as OWASP API Top 10.

Remediation focuses on preventing untrusted data derived from Bearer Tokens from reaching template engines and ensuring strict separation between authorization data and rendering logic. The following examples demonstrate secure patterns in Gin.

Example 1: Avoid passing token data directly to templates

Instead of injecting the raw Authorization header value into a template, extract only necessary, validated claims (e.g., user ID) and pass sanitized data. Use structured logging for audit trails rather than embedding tokens in rendered output.

package main

import (
    "net/http"
    "strings"

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

func main() {
    r := gin.Default()
    r.GET("/profile", func(c *gin.Context) {
        auth := c.GetHeader("Authorization")
        if auth == "" {
            c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "missing authorization header"})
            return
        }
        parts := strings.Split(auth, " ")
        if len(parts) != 2 || parts[0] != "Bearer" {
            c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "invalid authorization format"})
            return
        }
        token := parts[1]
        // Do NOT pass token directly to template: c.HTML(http.StatusOK, "profile.tmpl", gin.H{"Token": token})
        // Instead, validate and extract claims, then pass minimal data
        userID, err := validateTokenAndExtractUserID(token)
        if err != nil {
            c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "invalid token"})
            return
        }
        c.HTML(http.StatusOK, "profile.tmpl", gin.H{"UserID": userID})
    })
    r.Run()
}

func validateTokenAndExtractUserID(token string) (string, error) {
    // Placeholder: implement JWT validation or lookup
    return "user-123", nil
}

Example 2: Use context values for user data, not raw tokens

Store authorization-derived data in Gin’s context with typed values, keeping templates agnostic to security-sensitive strings.

func authMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        auth := c.GetHeader("Authorization")
        if auth == "" {
            c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "missing authorization header"})
            return
        }
        parts := strings.Split(auth, " ")
        if len(parts) != 2 || parts[0] != "Bearer" {
            c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "invalid authorization format"})
            return
        }
        token := parts[1]
        userID, err := validateTokenAndExtractUserID(token)
        if err != nil {
            c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "invalid token"})
            return
        }
        c.Set("userID", userID)
        c.Next()
    }
}

func profileHandler(c *gin.Context) {
    userID, _ := c.Get("userID")
    c.HTML(http.StatusOK, "profile.tmpl", gin.H{"UserID": userID})
}

Example 3: Disable template debugging and avoid eval-like features

Ensure your template engine is configured without debug or auto-reload features in production, and never use template functions that execute strings as code. If using third-party template libraries, apply strict sandboxing and avoid passing raw header values into template functions.

By treating Bearer Tokens as opaque, sensitive identifiers and never allowing them to directly influence template evaluation, you eliminate a class of Server Side Template Injection risks specific to authorization-header-driven rendering paths. middleBrick’s CLI tool (middlebrick scan <url>) can validate that token-derived data does not reach unsafe rendering contexts, while the GitHub Action helps enforce these rules in CI/CD pipelines.