Dns Rebinding in Fiber with Firestore

DNS rebinding is a client-side attack that manipulates DNS responses to make a browser believe a remote host is also a local host. When a Fiber-based backend exposes Firestore management operations to unauthenticated or overly permissive HTTP endpoints, rebinding can coerce the browser into sending privileged Firestore requests to a malicious host that controls DNS and can pivot to internal IPs.

Consider a Fiber route that accepts a document ID from a query parameter and retrieves data from Cloud Firestore without enforcing strict CORS or origin checks. An attacker registers a domain (evil.example) that initially resolves to a public IP hosting attacker-controlled JavaScript. After the victim loads the page, the attacker switches the DNS resolution to 127.0.0.1 or another internal address. If the Fiber app listens on 0.0.0.0 and exposes an endpoint like /api/firestore/doc that does not validate the request origin, the browser will send the request to the internal listener, potentially using credentials or metadata that the Firestore client would normally protect.

Firestore itself does not serve web pages, so the exposure typically occurs via a Fiber route that performs server-side reads or writes using the Firestore Admin SDK or a service account. If the route trusts any client-supplied input (such as a document path) and does not validate the caller’s origin, DNS rebinding can be used to trick the victim into triggering these server-side operations from a controlled malicious site. For example, the attacker’s JavaScript can create an Image or fetch request to the Fiber endpoint, causing the browser to resolve the domain to an internal IP and interact with the Firestore integration in an unintended context.

Because the attack relies on the browser’s same-origin policy and DNS behavior, protections must focus on server-side controls: strict CORS policies, origin validation, and avoiding the exposure of Firestore operations through endpoints that can be triggered cross-origin by malicious sites. middleBrick can help detect missing CORS controls and overly permissive origins as part of its unauthenticated scan, highlighting findings mapped to the OWASP API Top 10 and related to Security Misconfiguration.

To mitigate DNS rebinding risks when Fiber routes interact with Firestore, enforce strict origin validation and avoid using client-controlled input to build Firestore document paths or decide access logic. Use parameterized queries and whitelisted origins, and never rely on HTTP referers alone for authorization.

Example vulnerable Fiber route

The following example demonstrates an unsafe pattern where a document ID is taken directly from a query parameter and used with the Firestore Go SDK:

package main

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

	"github.com/gofiber/fiber/v2"
	"cloud.google.com/go/firestore"
	googleauth "google.golang.org/api/option"
)

func unsafeDocHandler(c *fiber.Ctx) error {
	client, err := firestore.NewClient(c.Context(), <project-id>, googleauth.WithoutAuthentication())
	if err != nil {
		return c.Status(http.StatusInternalServerError).SendString(err.Error())
	}
	defer client.Close()

	docID := c.Query("doc_id", "missing")
	ref := client.Collection("items").Doc(docID)
	doc, err := ref.Get(c.Context())
	if err != nil {
		return c.Status(http.StatusInternalServerError).SendString(err.Error())
	}
	if !doc.Exists() {
		return c.SendStatus(http.StatusNotFound)
	}
	return c.JSON(doc.Data())
}

Secured Fiber route with origin validation and strict parameter handling

Apply a strict allow-list of origins, reject requests with an empty origin, and avoid reflecting the origin header in responses. Use explicit parameter validation and limit Firestore access to known document patterns.

package main

import (
	"context"
	"fmt"
	"net/http"
	"strings"

	"github.com/gofiber/fiber/v2"
	"cloud.google.com/go/firestore"
	googleauth "google.golang.org/api/option"
)

var allowedOrigins = map[string]bool{
	"https://trusted.example.com": true,
	"https://app.example.com":     true,
}

func secureDocHandler(c *fiber.Ctx) error {
	origin := c.Get("Origin")
	if !allowedOrigins[origin] {
		return c.SendStatus(http.StatusForbidden)
	}

	client, err := firestore.NewClient(c.Context(), <project-id>, googleauth.WithoutAuthentication())
	if err != nil {
		return c.Status(http.StatusInternalServerError).SendString(err.Error())
	}
	defer client.Close()

	docID := c.Query("doc_id")
	if docID == "" || strings.Contains(docID, "/") {
		return c.Status(http.StatusBadRequest).SendString("invalid document id")
	}

	ref := client.Collection("items").Doc(docID)
	doc, err := ref.Get(c.Context())
	if err != nil {
		return c.Status(http.StatusInternalServerError).SendString(err.Error())
	}
	if !doc.Exists() {
		return c.SendStatus(http.StatusNotFound)
	}

	c.Set("Access-Control-Allow-Origin", origin)
	return c.JSON(doc.Data())
}

Additional recommendations:

• Use middleware to enforce CORS with allow-listed origins and avoid wildcards for privileged endpoints.
• Validate document IDs against a strict pattern (e.g., alphanumeric and limited length) to prevent path traversal or unintended collection access.
• If using service account credentials, keep them server-side and never expose Firestore admin operations to unauthenticated client-side calls.
• Enable Cloud Audit Logs for Firestore to monitor access patterns that may indicate abuse via rebinding or other client-side attacks.

These measures reduce the risk that a malicious site can induce a victim’s browser to trigger Firestore reads or writes through a Fiber endpoint.