Dns Rebinding in Fiber with Jwt Tokens

DNS rebinding is a network-based attack that manipulates DNS responses to make a victim’s browser believe a malicious host is a trusted origin. When this technique intersects with a Fiber-based API that relies on JWT tokens for authorization, the combination can expose authentication bypass and request smuggling risks. In a typical scenario, an attacker registers a domain (e.g., evil.com) pointing to a public IP under their control. The victim authenticates to your Fiber service, receives a JWT token, and then browses to the attacker’s page. The attacker’s page forces the victim’s browser to make requests to your API. Because the token is typically stored in memory or in an httpOnly cookie and sent automatically by the browser, these forged requests include the valid JWT.

The vulnerability arises when authorization decisions in Fiber depend solely on the presence and validity of a JWT without sufficient context about the request origin. For example, if your middleware validates the JWT signature and claims but does not enforce strict same-origin policies or validate the Host header, the browser’s redirected request will still carry the token. An endpoint that trusts the token to identify the user and performs sensitive operations (e.g., changing email or resetting password) can be invoked with the attacker’s intent, while appearing to come from the legitimate client IP. This can lead to privilege escalation or unauthorized actions because the JWT claims may indicate a high-privilege user, and the request appears to originate from a trusted source due to the browser’s same-origin allowances for cookies and headers.

Another angle involves token binding and CORS misconfigurations. If your Fiber application issues tokens after a successful login and relies on CORS to restrict origins, an incorrect wildcard policy or missing proper Origin validation can allow rebinding to bypass intended restrictions. The attacker can craft requests that the browser sends with credentials (cookies or Authorization headers containing the JWT) to your domain, even though the request is initiated from a different origin. Because the JWT is often used as a bearer token in the Authorization header, and browsers include headers set by JavaScript, the forged request reaches your endpoints with a valid token, and the server processes it as a legitimate user action.

To detect this risk using middleBrick, you can run a scan against your Fiber endpoints. The tool tests unauthenticated attack surfaces and can surface findings related to authentication bypass, CORS, and header handling that may interact with token-based flows. While middleBrick does not fix the issue, its findings include remediation guidance to help you adjust your authorization logic and validation rules.

Remediation focuses on ensuring that JWT validation is coupled with origin and Host header checks, and that tokens are not treated as a sufficient authorization proof without context. Below are concrete code examples for a Fiber-based API that illustrate secure handling.

First, use middleware that validates the JWT and then explicitly verifies the request’s Host and Origin. This prevents requests that appear to come from your domain but are actually rebinding attacks:

const jwtmiddleware = jwt.Middleware({
  signingKey: []byte(os.Getenv("JWT_SECRET")),
  signingMethod: jwt.SigningMethodHS256,
  userProperty: "user",
  authScheme: "Bearer",
})

app.Use(jwtmiddleware)

app.Use(func(c *fiber.Ctx) error {
  // Ensure the request Host matches your expected domain
  allowedHosts := []string{"api.yourdomain.com", "app.yourdomain.com"}
  host := c.Hostname()
  allowed := false
  for _, h := range allowedHosts {
    if host == h {
      allowed = true
      break
    }
  }
  if !allowed {
    return c.Status(fiber.StatusForbidden).JSON(fiber.Map{"error": "invalid host"})
  }
  // Optionally validate Origin header for cross-origin requests
  origin := c.Get("Origin")
  if origin != "" && origin != "https://app.yourdomain.com" {
    return c.Status(fiber.StatusForbidden).JSON(fiber.Map{"error": "invalid origin"})
  }
  return c.Next()
})

Second, when issuing tokens, avoid including sensitive permissions that could be abused if the token is replayed via rebinding. Instead, scope tokens tightly and consider short lifetimes. Here is an example of creating a JWT with limited scope:

token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
  "sub": userID,
  "role": "user",
  "scope": "read write profile",
  "exp": time.Now().Add(time.Minute * 15).Unix(),
  "nbf": time.Now().Unix(),
  "iss": "yourdomain.com",
  "aud": "api.yourdomain.com",
})
tokenString, err := token.SignedString([]byte(os.Getenv("JWT_SECRET")))
if err != nil {
  log.Fatal(err)
}

Third, enforce strict CORS settings in Fiber to reduce the window for credentialed cross-origin requests:

app.Use(cors.New(cors.Config{
  AllowOrigins:     []string{"https://app.yourdomain.com"},
  AllowMethods:     []string{fiber.MethodGet, fiber.MethodPost},
  AllowHeaders:     []string{fiber.HeaderOrigin, fiber.HeaderContentType, fiber.HeaderAuthorization},
  ExposeHeaders:    []string{"Content-Length"},
  AllowCredentials: true,
  MaxAge:           3600,
}))

Finally, consider binding tokens to the client IP or a nonce when high-security operations are performed. While this can complicate legitimate use across changing networks, it adds a layer of protection against token replay from a different network context after rebinding.