Request Smuggling in Fiber with Jwt Tokens

Request smuggling occurs when an application processes HTTP requests differently depending on whether they are handled by a frontend proxy or the backend application. In Fiber, this can be exposed when JWT tokens are handled via headers and the server parses requests in a way that diverges from the proxy’s interpretation. A common pattern in Fiber is to read the Authorization header and validate a JWT before routing the request. If the proxy normalizes or splits headers differently than Fiber does, an attacker can craft a request that the proxy interprets as one route while Fiber parses it as another.

For example, a frontend proxy might treat Content-Length: 0 and a separate Transfer-Encoding: chunked as a single normalized request, while Fiber processes them as two distinct request boundaries. When JWT tokens are passed in headers, the smuggling attempt can bypass authentication because the proxy may forward only the first request (with a valid-appearing JWT) to Fiber, while Fiber interprets the second request (which may lack a token or contain a different path) as part of the same connection. This can lead to BOLA/IDOR-like access if the second request targets a different user context, or it can allow unauthenticated smuggling paths to skip JWT validation entirely.

The 12 checks in middleBrick test this class of issue by sending requests that mix header parsing patterns (e.g., duplicate Content-Length and Transfer-Encoding) while including JWT tokens in headers. The scanner checks whether authentication is enforced consistently across parsed request boundaries and whether a JWT-less request can be smuggled into a path that should require a token. Findings often highlight missing uniformity in header normalization and insufficient validation of request structure when tokens are present.

To mitigate request smuggling in Fiber when using JWT tokens, ensure consistent header parsing and strict request boundary handling on the server side. Do not rely on the proxy to enforce authentication; validate the JWT on every request within Fiber and reject ambiguous or duplicated header combinations.

Use a strict middleware that validates the JWT before routing and explicitly rejects requests that contain both Content-Length and Transfer-Encoding or that have mismatched header casing that could confuse a proxy. Below is a secure Fiber example that decodes and validates a JWT from the Authorization header and rejects malformed or ambiguous requests.

// Secure Fiber JWT validation middleware
const { App } = require("github.com/gofiber/fiber/v2")
const jwt = require("github.com/golang-jwt/jwt/v5")

const app = new App()
const secretKey = "your-secret-key"

// Middleware to validate JWT and reject smuggling header combinations
app.use((req, res, next) => {
  // Reject requests with both Content-Length and Transfer-Encoding
  if (req.Header("Content-Length") && req.Header("Transfer-Encoding")) {
    return res.status(400).send({ error: "Ambiguous headers: Content-Length and Transfer-Encoding" })
  }

  const authHeader = req.Header("Authorization")
  if (!authHeader || !authHeader.startsWith("Bearer ")) {
    return res.status(401).send({ error: "Unauthorized: missing or malformed Authorization header" })
  }

  const tokenString = authHeader.substring(7)
  try {
    const decoded = jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
      // Validate signing method and key
      if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
        return null, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
      }
      return []byte(secretKey), nil
    })
    if claims, ok := decoded.Claims.(jwt.MapClaims); ok && decoded.Valid {
      req.Locals("user") = claims["sub"]
      return next()
    }
  } catch (err) {
    return res.status(401).send({ error: "Invalid token" })
  }

  return res.status(401).send({ error: "Invalid token" })
})

// Example protected route
app.get("/profile", (c *fiber.Ctx) => {
  user := c.Locals("user")
  return c.JSON({ message: "Profile for user " + user })
})

app.Listen(":3000")

This approach enforces a single interpretation of the request on the server and ensures that JWT validation occurs independently of how a proxy normalizes headers. By rejecting requests that mix Content-Length and Transfer-Encoding, you reduce the risk of a smuggled request bypassing authentication. middleBrick’s scans validate that such mitigations are present by checking for consistent handling of these headers alongside JWT usage.