HIGH distributed denial of servicefiberbasic auth

Distributed Denial Of Service in Fiber with Basic Auth

Distributed Denial Of Service in Fiber with Basic Auth — how this specific combination creates or exposes the vulnerability

A DDoS attack against a Fiber service protected only by HTTP Basic Auth can exploit the combination of cheap authentication verification and expensive request processing. Because Basic Auth credentials are sent in every request, an attacker can open many concurrent connections and send valid credentials, keeping the connections open and consuming server resources. In Fiber, each incoming connection uses a goroutine; an attacker that sustains many open requests can exhaust the Go runtime scheduler and the available worker threads, causing increased latency and timeouts for legitimate users.

When Basic Auth is used without additional protections, the authentication check happens early but does not limit resource consumption for the remainder of the request lifecycle. For example, if handlers perform heavy JSON parsing, database lookups, or call external services, an attacker can send many authenticated requests that trigger these costly operations. This amplifies the impact of what would otherwise be a simple credential check, turning authenticated requests into a resource exhaustion vector.

Another specific risk arises when the Basic Auth implementation leaks or varies response timing based on credential validity. If a server returns different status codes or response headers for invalid users, an attacker can probe for valid accounts while sustaining connections. Combined with missing rate controls, this allows both enumeration and resource starvation. The scanner checks for missing rate limiting and for authentication behaviors that can be abused in authenticated DDoS scenarios.

Because the scan is unauthenticated and tests the public attack surface, it can detect whether endpoints protected only by Basic Auth are missing complementary controls such as rate limiting, connection caps, or request size limits. Findings highlight the absence of these controls and map the issue to the OWASP API Top 10 and relevant compliance frameworks.

Basic Auth-Specific Remediation in Fiber — concrete code fixes

To reduce DDoS risk when using HTTP Basic Auth in Fiber, combine cheap credential validation with strict resource controls and request-cost management. Do not rely on Basic Auth alone as a DDoS mitigation; treat it as identification and layer additional protections.

Example of safe Basic Auth usage in Fiber with middleware that enforces per-IP request limits and constrains request body size:

package main

import (
	"net/http"
	"strings"

	"github.com/gofiber/fiber/v2"
	"github.com/gofiber/fiber/v2/middleware/limiter"
	"github.com/gofiber/fiber/v2/middleware/requestid"
)

func main() {
	app := fiber.New()

	// Limit the number of requests per IP to mitigate flooding
	app.Use(limiter.New(limiter.Config{
		Max:        100,          // max requests
		Expiry:     60,           // per 60 seconds
		Message:    "Too many requests",
		StatusCode: http.StatusTooManyRequests,
	}))

	// Optional: limit request body size to prevent large payload attacks
	app.Use("/*", requestid.New())

	// Basic Auth middleware with constant-time comparison pattern
	app.Use(func(c *fiber.Ctx) error {
		const validUser = "admin"
		const validPass = "SuperSecret123"

		user, pass, ok := c.BasicAuth()
		if !ok {
			return c.SendStatus(http.StatusUnauthorized)
		}

		// Avoid timing leaks by checking both credentials together
		if len(user) != len(validUser) || len(pass) != len(validPass) {
			c.Set(fiber.HeaderWWWAuthenticate, `Basic realm="restricted"`)
			return c.SendStatus(http.StatusUnauthorized)
		}

		if subtleCompare(user, validUser) && subtleCompare(pass, validPass) {
			return c.Next()
		}
		c.Set(fiber.HeaderWWWAuthenticate, `Basic realm="restricted"`)
		return c.SendStatus(http.StatusUnauthorized)
	})

	app.Get("/api/data", func(c *fiber.Ctx) error {
		return c.JSON(fiber.Map{"status": "ok"})
	})

	app.Listen(":3000")
}

// subtleCompare avoids early exit on mismatch to reduce timing attacks
func subtleCompare(a, b string) bool {
	if len(a) != len(b) {
		return false
	}
	var equal byte
	for i := 0; i < len(a); i++ {
		equal |= a[i] ^ b[i]
	}
	return equal == 0
}

Key remediation points:

  • Rate limiting at the middleware level restricts the number of requests per IP or token, reducing the effectiveness of connection-sustenance attacks.
  • Limit request and body sizes to prevent resource-intensive parsing of large payloads.
  • Use constant-time comparison for credentials to avoid timing-based user enumeration that can aid attackers in targeted authentication DDoS.
  • Combine Basic Auth with additional mechanisms such as short-lived tokens or IP allowlists where feasible to reduce exposure of long-lived credentials.

The scanner validates whether rate limiting and input size controls are present and flags endpoints that rely solely on Basic Auth for abuse prevention.

Frequently Asked Questions

Can HTTP Basic Auth alone stop DDoS attacks?
No. Basic Auth provides credentials but does not limit request volume or resource consumption. You must add rate limiting, connection caps, and request-size controls to reduce DDoS risk.
What does the scanner check for regarding DDoS with Basic Auth?
It checks whether endpoints protected only by Basic Auth have complementary rate limiting, request size limits, and whether authentication responses avoid timing differences that could enable probing while sustaining connections.