Cross Site Request Forgery in Gin with Basic Auth

Cross Site Request Forgery (CSRF) in a Gin API that uses HTTP Basic Authentication involves a specific risk pattern: the combination of browser-based cookie storage and automatic credential transmission can enable unauthorized actions even when credentials themselves are not stored in cookies. Basic Auth credentials are typically sent via the Authorization header, but browsers also maintain session cookies for the domain. If your Gin application sets session or other state-related cookies alongside Basic Auth usage, and those cookies are not properly protected, a forged request from a malicious site can include both the browser-authenticated context and any cookies, leading to unauthorized operations.

Consider a Gin endpoint that changes an email address or updates a profile. If the endpoint relies solely on the presence of a valid Authorization header (username:password encoded in Base64) and also uses a session cookie for additional state, an attacker can craft a form on a malicious site that submits to your endpoint. When a victim who is logged into your service via Basic Auth visits the attacker site, the browser automatically attaches both the Authorization header (if the site triggers a fetch with credentials) and any related cookies. Because the Gin handler does not validate the origin of the request beyond credential presence, the action is executed as the victim. This illustrates how CSRF leverages the browser’s automatic inclusion of authentication-related headers and cookies, even when Basic Auth is in play.

In practice, this risk is more likely when Basic Auth is used in a web-facing API consumed by browsers, rather than in purely machine-to-machine contexts. Attack vectors such as OWASP API Top 10 A05:2023 — Broken Function Level Authorization (BFLA) can intersect with CSRF if privileged endpoints lack proper ownership checks and also rely on browser-automated credentials. For example, an endpoint like /user/{id}/change-email might verify that a token or Basic Auth credentials are present, but fail to ensure that the {id} in the URL matches the user making the request, compounding CSRF risk with BOLA/IDOR concerns. Real-world examples involving exposed endpoints with permissive CORS policies or missing anti-CSRF tokens further demonstrate how the interplay between Basic Auth and session cookies can be abused.

To detect such issues, scanners perform active probes that attempt to submit forged requests from a different origin and observe whether the Gin endpoint executes actions without explicit anti-CSRF mechanisms. These checks align with broader Security Misconfiguration and Broken Access Control reviews, highlighting the importance of validating request origins and ensuring that state-changing methods require more than automatically transmitted credentials.

Remediation focuses on ensuring that state-changing operations require explicit verification beyond the presence of Basic Auth credentials. In Gin, you should avoid relying on cookies for authorization decisions and instead treat each request as independent. Where cookies are necessary for session management, enforce strict SameSite attributes, Secure flags, and HttpOnly settings. For APIs, prefer token-based approaches where each request includes an explicit bearer token that can be validated without relying on browser cookie behavior.

When Basic Auth is required, implement additional context checks. For example, validate that the resource being modified belongs to the authenticated user, and use anti-CSRF tokens for any browser-initiated actions. The following code demonstrates a secure Gin pattern that combines Basic Auth parsing with per-request user context validation and explicit CSRF token verification for state-changing methods.

// Basic Auth parsing middleware in Gin
func BasicAuthMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        user, pass, ok := c.Request.BasicAuth()
        if !ok {
            c.AbortWithStatusJSON(401, gin.H{"error": "authorization required"})
            return
        }
        // Validate user and pass against your secure store
        if !isValidUser(user, pass) {
            c.AbortWithStatusJSON(401, gin.H{"error": "invalid credentials"})
            return
        }
        // Set user in context for downstream handlers
        c.Set("user", user)
        c.Next()
    }
}

// Handler that requires both auth and CSRF protection for browser clients
func UpdateEmailHandler(c *gin.Context) {
    user, exists := c.Get("user")
    if !exists {
        c.AbortWithStatusJSON(401, gin.H{"error": "unauthorized"})
        return
    }
    // Expect CSRF token in header for state-changing operations from browsers
    token := c.GetHeader("X-CSRF-Token")
    if !validateCSRFToken(user.(string), token) {
        c.AbortWithStatusJSON(403, gin.H{"error": "invalid CSRF token"})
        return
    }
    var req struct {
        Email string `json:"email" binding:"required,email"`
    }
    if err := c.ShouldBindJSON(&req); err != nil {
        c.AbortWithStatusJSON(400, gin.H{"error": err.Error()})
        return
    }
    // Ensure user can only modify their own email
    if !userCanModifyEmail(user.(string), req.Email) {
        c.AbortWithStatusJSON(403, gin.H{"error": "forbidden"})
        return
    }
    // Perform update
    if err := updateUserEmail(user.(string), req.Email); err != nil {
        c.AbortWithStatusJSON(500, gin.H{"error": "internal error"})
        return
    }
    c.JSON(200, gin.H{"status": "email updated"})
}

// Example CSRF token validation (simplified)
func validateCSRFToken(user, token string) bool {
    // In practice, use per-session or per-request tokens stored server-side
    return token != "" && token == generateExpectedToken(user)
}

// Example user ownership check
func userCanModifyEmail(user, email string) bool {
    // Lookup user and compare with request email
    return user == email // simplified for example
}

For purely API clients (non-browser), CSRF risk is lower, but you should still enforce strict authentication and ensure that endpoints validate resource ownership. Using the Gin CLI tool, you can scan your endpoints with middlebrick scan <url> to identify missing anti-CSRF protections and BFLA issues. Teams using CI/CD can integrate the GitHub Action to fail builds when risk scores drop below a defined threshold, ensuring that regressions such as missing origin checks or weak authorization logic are caught before deployment.