Insecure Direct Object Reference in Echo Go with Firestore

Insecure Direct Object Reference (BOLA/IDOR) occurs when an API exposes a reference to an internal object—such as a Firestore document ID—and allows an authenticated user to access or modify data that should be restricted. In an Echo Go service that uses Firestore, this commonly arises when an endpoint accepts a user-supplied document ID or numeric record key (e.g., /users/{id}) and directly queries Firestore without confirming that the authenticated subject has permission to access that specific document.

Consider an Echo Go handler that retrieves a user profile using a path parameter uid and queries Firestore for that document. If the handler only checks that the caller is authenticated (via JWT or session) but does not verify ownership or authorization of the requested uid, an attacker can change the uid to another user’s document ID and read or manipulate data they should not see. Because Firestore document IDs are often predictable or enumerable, this creates a classic BOLA/IDOR vector.

For example, an endpoint like GET /api/v1/users/{uid} might decode the JWT to obtain subject information but then directly run db.Collection("users").Doc(uid).Get(ctx). An attacker can intercept the request and replace uid with another valid user document ID. Firestore will return the document if read permissions are open at the database level, and the Go handler may return it as if it were the authenticated user’s data. This is an IDOR because the authorization decision is missing or incorrect at the document level, not at the collection or broader service level.

Echo Go does not enforce authorization; it is a lightweight HTTP framework. Responsibility for ensuring that a given Firestore document is accessible only to authorized subjects falls entirely on the application code. Without explicit checks—such as comparing the authenticated user ID from the JWT with the Firestore document’s owner field or implementing a policy check before the query—an IDOR exists. Firestore security rules can help, but they are not a substitute for server-side authorization in application logic, especially when rules are permissive for convenience during development.

Real-world impact can be significant. An attacker might enumerate sequential IDs or guess valid document keys to harvest PII, alter settings, or escalate privileges if the exposed documents contain administrative flags. This pattern is frequently flagged by middleBrick’s BOLA/IDOR checks, which correlate runtime requests with Firestore document reads to detect missing ownership validation. Because Firestore document IDs are often included in URLs or API responses, they become natural reference points for abuse when authorization is overlooked.

Remediation centers on ensuring that every Firestore document access is preceded by an explicit authorization check that ties the document to the authenticated subject. Below are concrete patterns and code examples for Echo Go services using Firestore.

1. Always compare authenticated identity with document metadata

After retrieving the document, compare a field that indicates ownership (e.g., owner_uid) with the subject from the JWT. Do not rely solely on the document being present or on Firestore rules alone.

// Example: Echo Go handler with Firestore ownership check
import (
	"context"
	"net/http"

	"github.com/labstack/echo/v4"
	"cloud.google.com/go/firestore"
	"google.golang.org/api/iterator"
)

type UserProfile struct {
	OwnerUID string `firestore:"owner_uid"`
	Name     string `firestore:"name"`
	Email    string `firestore:"email"`
}

func GetUserProfile(c echo.Context) error {
	uid := c.Param("uid")
	user := c.Get("user").(*User) // authenticated subject from JWT
	ctx := c.Request().Context()

	client, err := firestore.NewClient(ctx, "your-project-id")
	if err != nil {
		return echo.NewHTTPError(http.StatusInternalServerError, "failed to create client")
	}
	defer client.Close()

	docRef := client.Collection("users").Doc(uid)
	docSnap, err := docRef.Get(ctx)
	if err != nil {
		// Do not reveal whether the document exists; generic message
		return echo.NewHTTPError(http.StatusNotFound, "user not found")
	}

	var profile UserProfile
	if err := docSnap.DataTo(&profile); err != nil {
		return echo.NewHTTPError(http.StatusInternalServerError, "failed to parse data")
	}

	// Critical authorization check: ensure the authenticated user owns this document
	if profile.OwnerUID != user.Subject {
		return echo.NewHTTPError(http.StatusForbidden, "access denied")
	}

	return c.JSON(http.StatusOK, profile)
}

2. Use Firestore queries that enforce ownership at the database read level

Instead of fetching by document ID, query the collection with a composite filter that includes the owner UID. This reduces reliance on the client-supplied ID and ensures the server only returns documents the subject is allowed to see.

// Example: Query-based access control in Echo Go
func ListUsersForMe(c echo.Context) error {
	user := c.Get("user").(*User)
	ctx := c.Request().Context()

	client, err := firestore.NewClient(ctx, "your-project-id")
	if err != nil {
		return echo.NewHTTPError(http.StatusInternalServerError, "failed to create client")
	}
	defer client.Close()

	iter := client.Collection("users").
		Where("owner_uid", "==", user.Subject).
		Documents(ctx)
	defer iter.Stop()

	var results []UserProfile
	for {
		docSnap, err := iter.Next()
		if err == iterator.Done {
			break
		}
		if err != nil {
			return echo.NewHTTPError(http.StatusInternalServerError, "failed to iterate")
		}
		var up UserProfile
		if err := docSnap.DataTo(&up); err != nil {
			continue // skip malformed entries
		}
		results = append(results, up)
	}

	return c.JSON(http.StatusOK, results)
}

3. Validate and sanitize path parameters

Ensure that IDs extracted from the URL are in the expected format to prevent some enumeration and injection-like issues. Combine this with server-side checks rather than trusting the ID alone.

// Basic validation example
import "regexp"

var idRegex = regexp.MustCompile(`^[a-zA-Z0-9_-]{1,100}$`)

func ValidateID(id string) bool {
	return idRegex.MatchString(id)
}

By combining ownership checks, query-based filtering, and input validation, you mitigate BOLA/IDOR risks in Echo Go applications backed by Firestore. These patterns align with the remediation guidance provided in middleBrick findings, which highlight missing document-level authorization as a key concern.