Information Disclosure in Fiber with Jwt Tokens

Information disclosure in a Fiber application that uses JWT tokens typically occurs when token contents or related authentication details are exposed to unauthorized parties. Because JWTs are often transported in HTTP headers (e.g., Authorization: Bearer <token>), logs, error messages, or responses, improper handling can reveal sensitive claims, signing keys, or token structure. In a black-box scan, middleBrick tests unauthenticated endpoints and checks whether authentication mechanisms are bypassed or whether tokens are inadvertently exposed through verbose errors or misconfigured CORS. One common root cause is inconsistent validation: if an endpoint accepts JWTs but does not uniformly enforce authorization, an attacker can probe IDs or parameters to learn whether accounts exist or which roles are assigned (BOLA/IDOR). This becomes information disclosure when error responses differentiate between ‘invalid token’ and ‘invalid resource ID’, revealing internal details about users or data relationships. Another vector involves introspection or debug endpoints that return decoded JWT payloads without proper access controls, effectively leaking identity and permission data. Because JWTs often carry user identifiers (sub), roles (scopes or groups), and expiration metadata, exposure through logs or error pages can aid lateral movement or privilege escalation. middleBrick’s checks include Authentication, Property Authorization, and Input Validation to detect whether token handling leaks information via status code differences, verbose messages, or missing authorization on token-introspection endpoints. The scanner also evaluates whether responses contain sensitive data patterns (e.g., keys, secrets, PII) and tests for SSRF that could pull internal metadata tied to service accounts using JWTs.

Remediation focuses on ensuring JWT validation is strict, uniform, and side-channel resistant in a Fiber application. First, always validate the token on the server before processing any request, and return the same generic error for invalid tokens regardless of whether the token is malformed, expired, or valid but unauthorized. This prevents information disclosure through differing error messages. Use a well-audited library such as github.com/golang-jwt/jwt to parse and verify signatures rather than custom parsing. Enforce strong algorithms (e.g., HS256 or RS256) and explicitly set expected issuer, audience, and expiration claims. Protect endpoints by attaching a middleware that checks permissions consistently and avoids branching logic that reveals which part failed (token vs. resource ownership).

Example: Secure JWT validation and authorization in Fiber

// main.go
package main

import (
	"github.com/gofiber/fiber/v2"
	"github.com/gofiber/fiber/v2/middleware/logger"
	"github.com/golang-jwt/jwt/v5"
)

// secret should be loaded from a secure source (e.g., environment variable)
var jwtSecret = []byte("super-secret-key-32-bytes-long-enough-for-hs256")

func verifyToken(c *fiber.Ctx) error {
	auth := c.Get("Authorization")
	if len(auth) < 7 || auth[:7] != "Bearer " {
		// Generic response to avoid signaling which part failed
		return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{
			"error": "unauthorized",
		})
	}
	tokenString := auth[7:]
	token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
		// Ensure the signing method is what you expect
		if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
			return nil, jwt.ErrSignatureInvalid
		}
		return jwtSecret, nil
	})
	if err != nil || !token.Valid {
		return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{
			"error": "unauthorized",
		})
	}
	// Attach claims to context for downstream handlers
	if claims, ok := token.Claims.(jwt.MapClaims); ok && token.Valid {
		c.Locals("claims", claims)
		return c.Next()
	}
	return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{
		"error": "unauthorized",
	})
}

func adminHandler(c *fiber.Ctx) error {
	claims, ok := c.Locals("claims").(jwt.MapClaims)
	if !ok {
		return c.Status(fiber.StatusForbidden).JSON(fiber.Map{
			"error": "forbidden",
		})
	}
	// Check a custom role claim; keep responses generic
	if role, exists := claims["role"]; !exists || role != "admin" {
		return c.Status(fiber.StatusForbidden).JSON(fiber.Map{
			"error": "forbidden",
		})
	}
	// Proceed with admin action
	return c.JSON(fiber.Map{"status": "ok"})
}

func main() {
	app := fiber.New()
	app.Use(logger.New())
	app.Get("/admin", verifyToken, adminHandler)
	app.Listen(":3000")
}

In this example, token verification and authorization are centralized in verifyToken, which returns a consistent error for any invalid or missing token. Claims are extracted and checked in adminHandler without exposing which check failed. This reduces information leakage and aligns with secure handling of JWT tokens. middleBrick’s scans can validate that such responses do not leak stack traces or internal identifiers and that authorization is enforced on protected endpoints.