Webhook Abuse in Fiber with Jwt Tokens

Webhook abuse in a Fiber application that uses JWT tokens typically arises when webhook endpoints accept incoming HTTP requests without robust validation of the event source and without treating JWTs as bearer tokens that must be verified for each outbound call. A common pattern is for Fiber handlers to publish events by making HTTP requests to third‑party webhook URLs, attaching a JWT in the Authorization header as a bearer token. If the application does not validate the JWT before sending it, or if it reuses a token with broad scopes across many webhook destinations, an attacker who can influence event data or headers may be able to redirect webhooks, tamper with claims, or force the token to be presented to unintended services.

Consider a Fiber route that accepts an internal event and forwards it to a configured webhook URL, adding an Authorization bearer token from a stored JWT. If the webhook URL is user‑supplied and the JWT is not scoped with tight audience and issuer validation, an attacker can supply a malicious webhook endpoint. The request may then carry the JWT to an endpoint that does not expect it or that interprets the token as authorization to perform privileged actions. This can lead to unauthorized data access, token exfiltration if logs capture the header, or privilege escalation when the token has elevated scopes.

Another vector involves token leakage through webhook retries or error handling. For example, if a downstream service responds with a 401 and the Fiber handler retries the request without refreshing or validating the JWT, the same token may be sent to an incorrect audience. Because JWTs often contain scopes or roles, an attacker who can influence which webhook is called may be able to leverage a token intended for a limited service to access more privileged APIs. This matches patterns seen in broken object level authorization (BOLA) where the lack of per‑request audience and scope checks allows horizontal or vertical privilege escalation across webhook integrations.

Insecure transport and missing audience validation exacerbate the risk. If the JWT is transmitted over non‑TLS webhook calls, or if the Fiber application does not validate the iss, aud, and exp claims when the token is used for outbound webhook calls, an attacker on the network path can intercept or tamper with the token. Real‑world API security scans often flag missing audience validation and unencrypted webhook delivery as high‑severity findings because they enable token replay and webhook redirection attacks.

To detect this combination during a scan, tools like middleBrick run checks for unauthenticated webhook endpoints and for API calls that include bearer tokens without proper validation. The scan tests whether webhook URLs are guessable or accept arbitrary origins, and whether JWT usage includes audience and issuer verification. Findings highlight missing transport protections and missing per‑request scope checks, mapping to OWASP API Top 10 and relevant compliance controls.

Remediation focuses on strict JWT validation before any outbound webhook call, using audience and issuer checks, short‑lived tokens, and per‑request scope verification. Below are concrete, working examples for Fiber that demonstrate secure handling.

// secure_webhook.go
package main

import (
	"context"
	"fmt"
	"log"
	"net/http"
	"time"

	"github.com/gofiber/fiber/v2"
	"github.com/gofiber/fiber/v2/middleware/logger"
	jwtmiddleware "github.com/appleboy/fiber-jwt/v2"
	"github.com/dgrijalva/jwt-go"
)

// Claims represents the validated JWT payload used for webhook calls.
type Claims struct {
	Scope string `json:"scope"`
	Aud   string `json:"aud"`
	Iss   string `json:"iss"`
	jwt.StandardClaims
}

// verifyWebhookJWT validates the JWT intended for a webhook request.
// It enforces audience, issuer, and expiration checks.
func verifyWebhookJWT(tokenString, expectedAudience, expectedIssuer string) (*Claims, error) {
	keyFunc := func(token *jwt.Token) (interface{}, error) {
		// In production, use a proper key management approach.
		return []byte("your-secret-key"), nil
	}
	token, err := jwt.ParseWithClaims(tokenString, &Claims{}, keyFunc)
	if err != nil {
		return nil, fmt.Errorf("invalid token: %w", err)
	}
	claims, ok := token.Claims.(*Claims)
	if !ok || !token.Valid {
		return nil, fmt.Errorf("invalid claims")
	}
	if claims.Aud != expectedAudience {
		return nil, fmt.Errorf("invalid audience")
	}
	if claims.Iss != expectedIssuer {
		return nil, fmt.Errorf("invalid issuer")
	}
	if time.Now().After(time.Unix(claims.ExpiresAt, 0)) {
		return nil, fmt.Errorf("token expired")
	}
	// Ensure required scope for the webhook action.
	if claims.Scope != "webhook:send" {
		return nil, fmt.Errorf("insufficient scope")
	}
	return claims, nil
}

// sendWebhook makes an outbound webhook call with a validated JWT.
func sendWebhook(ctx context.Context, webhookURL string, claims *Claims) error {
	client := &http.Client{Timeout: 10 * time.Second}
	req, err := http.NewRequestWithContext(ctx, "POST", webhookURL, nil)
	if err != nil {
		return fmt.Errorf("failed to create request: %w", err)
	}
	req.Header.Set("Authorization", fmt.Sprintf("Bearer %s", claims.Extra("raw").(string))) // use a securely stored raw token
	req.Header.Set("Content-Type", "application/json")
	// Enforce audience and issuer at the point of use.
	q := req.URL.Query()
	q.Add("aud", claims.Aud)
	q.Add("iss", claims.Iss)
	req.URL.RawQuery = q.Encode()

	resp, err := client.Do(req)
	if err != nil {
		return fmt.Errorf("webhook request failed: %w", err)
	}
	defer resp.Body.Close()
	if resp.StatusCode < 200 || resp.StatusCode >= 300 {
		return fmt.Errorf("webhook returned non‑success status: %d", resp.StatusCode)
	}
	return nil
}

func main() {
	app := fiber.New()
	app.Use(logger.New())

	// Example protected route that triggers a webhook with a verified JWT.
	app.Post("/trigger", func(c *fiber.Ctx) error {
		// In practice, retrieve the JWT securely; here we parse from a trusted source.
		tokenString := c.Get("X-Internal-Token")
		claims, err := verifyWebhookJWT(tokenString, "webhook-service.example.com", "fiber-auth.example.com")
		if err != nil {
			return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "invalid_token"})
		}
		if err := sendWebhook(c.Context(), "https://webhook.example.com/events", claims); err != nil {
			return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
		}
		return c.JSON(fiber.Map{"status": "dispatched"})
	})

	log.Fatal(app.Listen(":3000"))
}

The key remediation steps encoded in this example are:

• Validate the JWT on the server side before using it for outbound calls, checking iss, aud, exp, and required scope.
• Avoid reusing a single JWT across many webhook destinations; scope tokens per integration and per audience.
• Use short‑lived tokens and refresh them securely; do not rely on long‑lived bearer tokens for webhook dispatch.
• Enforce TLS for all webhook requests and do not send tokens over non‑encrypted channels.
• Log minimal information and avoid including raw JWTs in logs to prevent accidental exfiltration.

In addition to code fixes, apply operational practices such as rotating signing keys, restricting webhook URL configuration to trusted administrators, and monitoring for repeated 401 responses that may indicate token misuse. These measures reduce the likelihood of webhook abuse and limit the impact of a compromised JWT.