Cross Site Request Forgery in Fiber with Basic Auth

Cross Site Request Forgery (CSRF) in the Fiber web framework when Basic Authentication is used centers on how credentials are transmitted and how the framework handles request origins. Basic Auth sends credentials in an Authorization header encoded as base64, not a cryptographically protected token, so if a user remains authenticated in a browser session an attacker can trick the user into issuing requests that include that header automatically via browser mechanisms.

Consider a Fiber endpoint that relies solely on Basic Auth for access control without anti-CSRF measures. Because the browser automatically attaches the Authorization header to same-origin and cross-origin requests when the user is logged in, an attacker can craft an HTML form or an image tag pointing to that endpoint. If the victim’s browser has cached or stored the credentials (or the user has not logged out), the forged request will be processed with the victim’s privileges, leading to unauthorized actions such as changing settings or invoking admin-only handlers.

CSRF risk with Basic Auth in Fiber is heightened when endpoints are not explicitly designed to reject cross-origin requests or validate the request source. The attack flow is specific: the victim must have valid Basic Auth credentials, and the browser must send those credentials automatically. Unlike token-based approaches, Basic Auth lacks built-in protections like same-site attributes or cryptographic nonces, so the framework must implement additional checks.

A realistic scenario: an authenticated user visits a malicious site while logged into a Fiber service that uses Basic Auth for admin routes. The malicious site contains a form with method POST and action pointing to the Fiber admin endpoint that mutates state. Because the browser includes the Authorization header automatically, the server may process the request as legitimate unless the server validates the Origin or Referer header, enforces explicit same-site policies, or requires a CSRF token.

In a black-box scan using middleBrick, endpoints relying on Basic Auth without anti-CSRF controls can receive a high severity finding under the BOLA/IDOR and Authentication checks, indicating that cross-origin requests may be accepted without proof of explicit consent. The scanner checks whether state-changing methods (POST, PUT, DELETE) are protected by origin validation or synchronizer tokens, and flags cases where credentials are transmitted via Basic Auth without additional CSRF mitigations.

middleBrick’s scans, which include checks for unsafe consumption patterns and property authorization, help surface these risks without requiring credentials. By submitting the API URL to middleBrick, teams can identify endpoints that depend exclusively on Basic Auth and lack CSRF defenses, enabling developers to apply targeted remediation before attackers exploit the gap.

Remediating CSRF when using Basic Auth in Fiber requires explicit measures that prevent unauthorized cross-origin requests and ensure each state-changing action includes proof of intent. The following concrete steps and code examples assume familiarity with Fiber’s middleware chaining and context handling.

1) Validate the Origin and Referer headers on state-changing routes. This approach rejects requests that do not originate from an expected domain. The following Fiber handler demonstrates this check:

package main

import (
    "github.com/gofiber/fiber/v2"
    "net/http"
    "strings"
)

func csrfMiddleware(c *fiber.Ctx) error {
    origin := c.Get("Origin")
    referer := c.Get("Referer")
    allowedOrigin := "https://your-trusted-domain.com"
    if origin != allowedOrigin && referer == "" || !strings.HasPrefix(referer, allowedOrigin) {
        return c.Status(http.StatusForbidden).SendString("invalid origin")
    }
    return c.Next()
}

func main() {
    app := fiber.New()
    app.Use(csrfMiddleware)
    app.Post("/admin/update", func(c *fiber.Ctx) error {
        // handle update
        return c.SendString("updated")
    })
    app.Listen(":3000")
}

2) Implement anti-CSRF tokens for Basic Auth-protected endpoints. Generate a per-session or per-request token and require it in a custom header or form field. The example below uses a simple token stored in a cookie and validated on submission:

import "github.com/gofiber/fiber/v2/middleware/csrf"

func main() {
    app := fiber.New()
    // Configure CSRF middleware with cookie-based token
    app.Use(csrf.New(csrf.Config{
        CookieHTTPOnly: true,
        CookieSecure:   true,  // set true in production over HTTPS
    }))

    app.Post("/secure-action", csrf.Protect, func(c *fiber.Ctx) error {
        // The request is verified to include a valid CSRF token
        return c.SendString("action confirmed")
    })
    app.Listen(":3000")
}

3) Enforce same-site cookie attributes if session identifiers are stored in cookies alongside Basic Auth. While Basic Auth typically relies on headers, some integrations may store auxiliary session data; setting SameSite=Strict or Lax prevents the browser from sending cookies on cross-origin requests:

app.Use("sessionConfig", session.New(session.Config{
    CookieSameSite: fiber.CookieSameSiteStrictMode,
    CookieSecure:   true,
}))

4) Combine Basic Auth with explicit CORS policies to restrict which origins can make authenticated requests. This reduces the attack surface by ensuring only trusted domains can include credentials:

import "github.com/gofiber/cors"

func main() {
    app := fiber.New()
    c := cors.New(cors.Config{
        AllowOrigins: "https://your-trusted-domain.com",
        AllowMethods: "GET,POST",
        AllowHeaders: "Authorization,Content-Type",
    })
    app.Use(c)
    app.Get("/data", func(c *fiber.Ctx) error {
        // Only requests from allowed origin with Basic Auth header will succeed
        return c.SendString("data")
    })
    app.Listen(":3000")
}

These remediation steps ensure that even when Basic Auth is used, CSRF risks are mitigated through origin validation, synchronizer tokens, and strict CORS rules. middleBrick scans can verify the presence of these controls by testing endpoints with and without cross-origin headers, helping teams confirm that state-changing actions require explicit consent.