Api Rate Abuse in Gin with Mongodb

Rate abuse in a Gin-based API that uses MongoDB as the backend datastore typically arises when rate-limiting controls are applied at the application layer only, or when per-user limits are derived from data stored in MongoDB. Without a dedicated, pre-authentication throttle, an unauthenticated attacker can open many connections to Gin endpoints and perform credential stuffing, brute-force login, or scraping that exhausts database resources and degrades service. Because Gin does not enforce limits natively, developers often implement middleware that counts requests using a MongoDB collection keyed by IP or API key. This approach can be unsafe: the counting operation itself performs a read followed by a conditional write, which may not be atomic, leading to race conditions that allow an attacker to exceed intended limits. Additionally, if the stored request count is not capped with a TTL, the MongoDB collection grows indefinitely and becomes both a performance and availability risk. In a black-box scan, middleBrick tests for insufficient rate limiting by sending rapid, unauthenticated requests to endpoints and checking whether repeated attempts are blocked. Findings include missing per-minute caps on authentication endpoints, lack of differentiation between authenticated and unauthenticated paths, and absence of sliding-window controls, which are especially important when user identifiers are drawn from MongoDB documents that may be slow to query under high concurrency.

To harden Gin handlers that rely on MongoDB for rate-state, enforce limits before any business logic and use atomic update operators to avoid race conditions. Prefer an in-memory token-bucket or fixed-window counter for low-latency checks, and reserve MongoDB for durable, longer-term controls or for storing per-user allowances after lightweight pre-checks. The following examples assume a Gin route for user login that must be limited to 5 attempts per username within a 60-second window.

1. Atomic increment with TTL using MongoDB updateOptions

Use an upsert with $inc and $set on an expires timestamp so that documents self-clean. This keeps counts bounded and reduces manual cleanup logic.

import (
	"context"
	"time"

	"go.mongodb.org/mongo-driver/bson"
	"go.mongodb.org/mongo-driver/mongo"
)

func allowAttempt(username string, coll *mongo.Collection) (bool, error) {
	ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
	defer cancel()

	// Atomic increment and set expiry in one operation
	res, err := coll.UpdateOne(
		ctx,
		bson.M{"_id": username},
		bson.M{
			"$inc": bson.M{"count": 1},
			"$set": bson.M{"expiresAt": time.Now().Add(2 * time.Minute).Unix(), "username": username},
		},
		options.Update().SetUpsert(true),
	)
	if err != nil {
		return false, err
	}

	// After increment, verify the current count
	var doc struct {
		Count     int64 `bson:"count"`
		ExpiresAt int64 `bson:"expiresAt"`
	}
	if err := coll.FindOne(ctx, bson.M{"_id": username}).Decode(&doc); err != nil {
		return false, err
	}

	if doc.Count > 5 {
		return false, nil
	}
	return true, nil
}

2. Sliding window stored as sorted set in MongoDB with TTL index

Store individual request timestamps in a sorted set keyed by IP or username. Use TTL on the documents holding per-user metadata and expire old timestamps with $pull in a controlled fashion. This approach approximates a sliding window more accurately than fixed windows.

func allowSliding(username string, coll *mongo.Collection) (bool, error) {
	now := time.Now()
	window := 60 // seconds
	cutoff := now.Add(-time.Duration(window) * time.Second)

	// Remove old entries atomically within a single operation context
	_, err := coll.UpdateOne(
		context.Background(),
		bson.M{"_id": username},
		bson.M{"$pull": bson.M{"requests": bson.M{"$lt": cutoff}}},
	)
	if err != nil {
		return false, err
	}

	// Count remaining and conditionally insert
	var doc struct {
		Requests []time.Time `bson:"requests"`
	}
	if err := coll.FindOne(context.Background(), bson.M{"_id": username}).Decode(&doc); err != nil && err != mongo.ErrNoDocuments {
		return false, err
	}

	if len(doc.Requests) >= 5 {
		return false, nil
	}

	// Push current timestamp and ensure TTL on parent document
	_, err = coll.UpdateOne(
		context.Background(),
		bson.M{"_id": username},
		bson.M{
			"$push": bson.M{"requests": now},
			"$set":  bson.M{"expiresAt": now.Add(2 * time.Minute).Unix()},
		},
		options.Update().SetUpsert(true),
	)
	return err == nil, err
}

3. Middleware integration in Gin with MongoDB-backed checks

Implement a Gin middleware that calls the atomic helper and returns 429 when the limit is reached. Keep the critical counting path fast by using in-memory caches for high-traffic paths and using MongoDB as a source of truth for longer windows or for authenticated contexts.

import (
	"github.com/gin-gonic/gin"
	"net/http"
)

func RateLimitMongo(coll *mongo.Collection) gin.HandlerFunc {
	return func(c *gin.Context) {
		user := c.Query("username")
		if user == "" {
			c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "username required"})
			return
		}
		allowed, err := allowAttempt(user, coll)
		if err != nil || !allowed {
			c.AbortWithStatusJSON(http.StatusTooManyRequests, gin.H{"error": "rate limit exceeded"})
			return
		}
		c.Next()
	}
}

By combining lightweight in-memory pre-screening with MongoDB-backed atomic updates and TTL-based data lifecycle, you reduce the risk of rate-abuse while keeping the database load bounded. middleBrick scans will validate whether these controls are present and whether authentication endpoints remain unprotected by per-user or per-IP limits.