Open Redirect in Fiber with Api Keys

An Open Redirect in a Fiber application that uses API keys can occur when a redirect target is derived from user-controlled input and API key validation is incomplete or misapplied. For example, a developer might implement a "return-to" or "next" parameter to redirect users after authentication or after a key-based action. If that parameter is taken directly from the request without strict validation, an attacker can supply a malicious external URL and cause the application to redirect authenticated users to arbitrary destinations.

When API keys are used for authentication, the risk pattern becomes: the API key proves identity, but the redirect logic does not verify intent or context. An API key does not prevent an open redirect; it only identifies the caller. If the endpoint accepting the API key also performs an unchecked redirect, the key can be abused in phishing scenarios where a legitimate domain leads users to malicious sites. Attackers may craft URLs such as /auth/redirect?api_key=VALID_KEY&next=https://evil.example.com, leveraging a valid key to increase trust and bypass browser defenses that might otherwise block unknown domains.

In practice, this misalignment between authentication (API key) and authorization (where the user is sent) mirrors broader classes of confusion between identity and intent. The vulnerability is not in the API key mechanism itself, but in how the application uses it in combination with dynamic redirects. Because the attack surface includes query or header-derived URLs, the scanner checks this as part of its BOLA/IDOR and Input Validation coverage, highlighting cases where a trusted origin can be weaponized via untrusted redirection targets.

To remediate open redirect risks in Fiber when using API keys, validate and restrict redirect destinations explicitly, and ensure API key checks do not implicitly authorize unsafe navigation. Below are concrete code examples that demonstrate a secure approach.

1. Validate redirect targets against an allowlist

package main

import (
	"net/http"
	"strings"

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

var allowedHosts = map[string]bool{
	"app.example.com": true,
	"dashboard.example.com": true,
}

func safeRedirect(c *fiber.Ctx) error {
	apiKey := c.Get("X-API-Key")
	if !isValidKey(apiKey) {
		return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "invalid api key"})
	}
	target := c.Query("next")
	if target == "" {
		target = "/dashboard"
	}
	parsed, err := url.Parse(target)
	if err != nil || !isAllowedHost(parsed.Host) {
		return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid redirect target"})
	}
	return c.Redirect(parsed.String(), fiber.StatusFound)
}

func isValidKey(key string) bool {
	// Compare against stored keys or a key service; constant-time compare preferred
	return key != "" && strings.HasPrefix(key, "ak_live_")
}

func isAllowedHost(host string) bool {
	return allowedHosts[host]
}

2. Use signed tokens instead of raw keys for redirect decisions

Instead of trusting a raw API key to authorize a redirect, issue a short-lived signed token that encodes the intended destination. This prevents tampering and ensures the server, not the client, decides the final URL.

package main

import (
	"time"

	"github.com/gofiber/fiber/v2"
	"github.com/golang-jwt/jwt/v5"
)

var jwtSecret = []byte("your-secret")

func issueRedirectToken(c *fiber.Ctx) error {
	apiKey := c.Get("X-API-Key")
	if !isValidKey(apiKey) {
		return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "invalid api key"})
	}
	target := c.Query("next")
	if target == "" || !isAllowedHostFromKey(apiKey, target) {
		target = "/dashboard"
	}
	token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
		"dest": target,
		"exp":  time.Now().Add(time.Minute * 5).Unix(),
	})
	signed, err := token.SignedString(jwtSecret)
	if err != nil {
		return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "unable to generate token"})
	}
	return c.JSON(fiber.Map{"redirect_token": signed})
}

func isValidKey(key string) bool {
	return key != "" && strings.HasPrefix(key, "ak_live_")
}

func isAllowedHostFromKey(key, host string) bool {
	// Implement key-to-host mapping, e.g., per-client allowed redirect domains
	return true // simplified for example
}

These examples emphasize that API keys authenticate the caller but must not be used as the sole mechanism for redirect authorization. Combining strict host allowlists, input parsing, and short-lived tokens ensures that even if a key is exposed, the application remains resilient against open redirect abuse.