Pii Leakage in Fiber with Jwt Tokens

In Go Fiber applications, JWT tokens are commonly used for authentication, but improper handling can lead to PII leakage across multiple layers of the API runtime. A typical scenario involves a Fiber route that decodes a JWT using a symmetric secret and then attaches user claims—including email, user ID, and role—to the request context for downstream handlers. If those handlers later include the request context or user struct in logs, error messages, or HTTP responses without redaction, PII can be exposed unintentionally. This often occurs when developers propagate the claims map or a user struct directly into response payloads or logging statements, revealing data such as emails or internal identifiers to unauthorized clients or observers.

Another leakage vector arises when OpenAPI specifications or generated docs inadvertently expose JWT-related endpoints alongside example responses that contain realistic PII. Because middleBrick performs OpenAPI/Swagger spec analysis with full $ref resolution and cross-references spec definitions with runtime findings, it can detect mismatches where documented example responses include email or other personal data that should not appear in production. Runtime probes can surface this when output scanning inspects responses for PII, API keys, and executable code in LLM or standard endpoint responses, highlighting gaps between documented behavior and secure implementation.

SSRF and unsafe consumption patterns can compound these risks. For example, if a Fiber handler uses data from JWT claims to construct outbound requests—such as a user-supplied redirect or webhook URL—an attacker might coerce the service into contacting an internal metadata service. Should that upstream response contain sensitive data, and if the handler forwards or logs it without validation, PII can leak through SSRF-assisted channels. middleBrick tests for SSRF and unsafe consumption in parallel with its 12 security checks, ensuring that the interaction between JWT-based routing and external calls is scrutinized for unintended data exposure.

Encryption and data exposure checks are particularly relevant when JWT tokens carry sensitive claims. If tokens are transmitted over non-TLS channels or logged at any layer, interception or log scraping can expose the payload contents. Even when TLS is enforced, storing or echoing claims in debug output or error pages introduces a data exposure surface. middleBrick’s encryption tests verify transport security and inspect response content for PII, API keys, and code fragments, providing a view into how JWT-driven workflows might unintentionally broadcast sensitive information.

Finally, the LLM/AI Security checks offered exclusively by middleBrick add a specialized lens to this scenario. System prompt leakage detection patterns can identify formatting or routing logic that might expose token-handling instructions, while active prompt injection probes test whether adversarial input can trick handlers into revealing claims or documentation. Output scanning for PII in LLM responses further ensures that AI-assisted tooling or logging does not amplify the exposure of user data when JWT claims are processed.

Remediation focuses on minimizing the scope of claims, enforcing transport security, and ensuring that PII never reaches logs, error messages, or responses. Below are concrete, idiomatic Fiber examples that demonstrate secure handling of JWT tokens.

1. Minimal claims and strict validation

Only include necessary identifiers in the token payload and avoid embedding PII such as email unless absolutely required. Validate the token rigorously and limit what you attach to the context.

// main.go
package main

import (
	"github.com/gofiber/fiber/v2"
	"github.com/gofiber/fiber/v2/middleware/jwt"
)

func main() {
	app := fiber.New()
	config := jwt.Config{
		SigningKey:   []byte("your-strong-secret-at-least-32-bytes-long"),
		ContextKey:   "uid", // minimal context key
		SigningMethod: "HS256",
	}
	app.Use(jwt.New(config))

	app.Get("/profile", func(c *fiber.Ctx) error {
		claims := jwt.ExtractClaims(c)
		uid, ok := claims["uid"].(string)
		if !ok {
			return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "invalid claims"})
		}
		// Use only the UID for downstream lookups; do not echo claims
		return c.JSON(fiber.Map{"userId": uid})
	})

	app.Listen(":3000")
}

2. Redact PII in logs and errors

Ensure that request-scoped data, including JWT claims, is never logged in full. Use structured logging with explicit field selection.

// logger.go
package main

import (
	"log"
	"github.com/gofiber/fiber/v2"
)

func safeLogger(c *fiber.Ctx, err error) {
	// Log only non-sensitive metadata
	log.Printf("request_id=%s method=%s path=%s status=%d err=%v",
		c.Locals("requestId"), c.Method(), c.Path(), c.Response().StatusCode(), err)
}

func ErrorHandler(c *fiber.Ctx, err error) error {
	safeLogger(c, err)
	return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"message": "internal error"})
}

3. Enforce TLS and secure token transmission

Always require HTTPS and set secure cookie flags if storing tokens in cookies. For Authorization: Bearer, ensure strict header parsing.

// secure.go
package main

import (
	"github.com/gofiber/fiber/v2"
	"github.com/gofiber/fiber/v2/middleware/compress"
)

func configureApp() *fiber.App {
	app := fiber.New(fiber.Config{
		SSL: fiber.SSLConfig{
			Redirect: true,
		},
	})
	app.Use(compress.New())
	return app
}

4. Isolate sensitive data from error and output paths

When decoding claims for business logic, copy only required fields into local variables and avoid passing the claims map or user struct directly to functions that may serialize or log them.

// handler.go
package main

import (
	"github.com/gofiber/fiber/v2"
)

type userCtx struct {
	UserID string `json:"userId"`
	Role   string `json:"role"`
}

func resolveUser(c *fiber.Ctx) (userCtx, error) {
	claims := jwt.ExtractClaims(c)
	return userCtx{
		UserID: toString(claims["uid"]),
		Role:   toString(claims["role"]),
	}, nil
}

func toString(v interface{}) string {
	if s, ok := v.(string); ok {
		return s
	}
	return ""
}

5. Middleware guardrails

Use middleware to strip or mask PII before it propagates. For example, avoid attaching full claims to the context; instead, attach a minimal DTO and ensure downstream handlers do not enrich outgoing responses with raw claims.

// guard.go
package main

import (
	"github.com/gofiber/fiber/v2"
	"github.com/gofiber/fiber/v2/middleware/jwt"
)

func claimFilter(next fiber.Handler) fiber.Handler {
	return func(c *fiber.Ctx) error {
		claims := jwt.ExtractClaims(c)
		// Only propagate non-sensitive identifiers
		c.Locals("principal", fiber.Map{
			"userId": claims["uid"],
			"role":   claims["role"],
		})
		return next(c)
	}
}