Cross Site Request Forgery in Gin with Mongodb

Cross Site Request Forgery (CSRF) in a Gin application that uses Mongodb can occur when state-changing requests rely only on cookies for authentication without additional anti-CSRF protections. In Go web apps using the Gin framework, if endpoints assume requests from authenticated browsers are legitimate simply because a valid session cookie or JWT is present, malicious sites can craft forms or JavaScript that trigger unwanted actions against the API. When the backend performs operations on Mongodb based on those requests, the unintended state changes happen in the database layer.

For example, a Gin route that deletes a user document from Mongodb based on a URL parameter is vulnerable if it does not validate the intent of the request origin. An attacker can register a malicious site that sends a request like DELETE /users/123 from the victim’s browser. If the victim has an active session cookie for the Gin app, the request will be authenticated by cookie, and the Gin handler may execute collection.DeleteOne on the targeted user ID without verifying that the request was intentionally made by the user. This becomes more impactful when the Gin app serves pages with cookies that authorize operations and embeds routes that mutate data via GET or unsafe methods, which is an anti-pattern that can be flagged by the OWASP API Top 10 and reflected in findings from middleBrick scans.

The risk is compounded when the Gin application exposes an OpenAPI spec that describes these mutation endpoints without requiring additional safeguards such as anti-CSRF tokens or explicit origin checks. middleBrick’s authentication and BOLA/IDOR checks can surface these issues by correlating unauthenticated attack surface tests with spec-defined routes, highlighting endpoints that accept state-changing methods without proper CSRF considerations. In a Mongodb context, this can lead to unauthorized document deletions, updates, or privilege escalations if the application logic incorrectly trusts the referrer or cookie alone. Proper defenses include synchronizer token patterns, SameSite cookies, and strict CORS rules, which reduce the likelihood that Mongodb operations are triggered by forged requests.

To remediate CSRF risks in Gin when interacting with Mongodb, implement anti-CSRF tokens and enforce strict request validation before performing any database operations. Below are concrete code examples for a Gin handler that safely deletes a user document from Mongodb only after verifying the request origin and token.

First, set SameSite cookies and include a CSRF token in forms or headers. For API-style endpoints, require a custom header (e.g., X-CSRF-Token) that must match a token stored in the session or a signed cookie. The following Gin handler demonstrates this approach with Mongodb using the official MongoDB Go driver:

//go
package main

import (
	"context"
	"net/http"
	"strings"

	"github.com/gin-gonic/gin"
	"go.mongodb.org/mongo-driver/bson"
	"go.mongodb.org/mongo-driver/mongo"
	"go.mongodb.org/mongo-driver/mongo/options"
)

func deleteUserHandler(client *mongo.Client) gin.HandlerFunc {
	return func(c *gin.Context) {
		// Expect CSRF token in header for API requests
		requestToken := c.GetHeader("X-CSRF-Token")
		cookieToken, err := c.Cookie("csrf_token")
		if err != nil || requestToken != cookieToken {
			c.AbortWithStatusJSON(http.StatusForbidden, gin.H{"error": "invalid csrf token"})
			return
		}

		userID := c.Param("id")
		if userID == "" {
			c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "missing user id"})
			return
		}

		// Safe Mongodb delete with context and explicit filter
		coll := client.Database("appdb").Collection("users")
		filter := bson.M{"_id": userID}
		result, err := coll.DeleteOne(c, filter)
		if err != nil || result.DeletedCount == 0 {
			c.AbortWithStatusJSON(http.StatusInternalServerError, gin.H{"error": "failed to delete user"})
			return
		}

		c.JSON(http.StatusOK, gin.H{"deleted": true})
	}
}

In this example, the Gin app requires the CSRF token to be present both in a header and in a cookie, and ensures they match before proceeding to delete a document by ID. The Mongodb operation uses a filtered DeleteOne with a context, avoiding unsafe direct parameter interpolation and preventing unintended deletions. To further reduce CSRF risk, configure CORS policies in Gin to restrict origins and avoid allowing credentials on wildcard domains. Middleware that validates HTTP methods and enforces anti-CSRF tokens for state-changing routes complements these protections and aligns with best practices referenced in compliance frameworks mapped by middleBrick findings.

Additionally, prefer POST, PUT, or DELETE over GET for mutations, validate and sanitize all inputs, and enforce authentication checks before each Mongodb operation. These steps make it significantly harder for attackers to exploit cross-site requests to manipulate your database, and they are reflected in the prioritized remediation guidance provided by middleBrick’s scans.