Pii Leakage in Gorilla Mux with Firestore

Pii Leakage in a Gorilla Mux and Firestore stack typically occurs when HTTP handlers expose Firestore document fields that contain personal data without applying field-level filtering or access controls. Gorilla Mux is a request router that matches incoming HTTP methods and path patterns to specific handler functions. If a handler retrieves a Firestore document and writes the entire document map to the response, fields such as email, phone number, address, or internal identifiers are exposed directly to the client.

The risk is heightened because Firestore documents often store user profiles, audit logs, or activity streams that include PII. When middleware or downstream code assumes the full document is safe to forward, sensitive fields can be serialized into JSON and returned over unencrypted channels or logged inadvertently. This becomes a compliance concern under frameworks such as GDPR and HIPAA, where data minimization is required and unnecessary exposure of PII must be prevented.

Another vector arises from query endpoints that return lists of documents. Without explicit projection or field masking, each document in the result set may contain sensitive attributes. For example, an endpoint like /users/{userID} might return the complete Firestore document including fields such as ssn, passwordHash, or internalNotes. Because Gorilla Mux does not enforce output policies by itself, developers must implement explicit allowlists of safe fields in the handler logic to avoid unintentional disclosure.

Additionally, Firestore security rules are not a substitute for application-level field filtering in this context. Rules can permit read access at the document level but cannot restrict which fields within that document are returned to the client. Therefore, even if rules block unauthorized users from reading certain documents, a privileged handler that returns the full document can still leak PII to authenticated but low-privilege users. This misalignment between database-level permissions and API output is a common root cause of Pii Leakage in Gorilla Mux integrations with Firestore.

Operational exposure can also occur through logging or error paths. If handlers log the full Firestore snapshot for debugging and those logs are aggregated in a central system, PII may be persisted in log stores beyond the intended retention window. Instrumentation that captures request and response payloads without redaction further increases the surface area. The combination of a flexible NoSQL store, permissive routing patterns, and missing output sanitization makes this stack particularly prone to PII exposure if secure coding practices are not consistently applied.

Remediation centers on explicit field selection and structured data transformation before sending any response. Instead of returning the raw Firestore document map, construct a minimal Data Transfer Object (DTO) that includes only the fields required by the client. This ensures PII is omitted regardless of how permissive Firestore rules may be.

Below is a concrete example of a secure handler using Firestore and Gorilla Mux. The handler retrieves a document by ID, validates ownership, and returns a sanitized response that excludes sensitive attributes such as email and phone number.

import (
    "context"
    "encoding/json"
    "net/http"

    "cloud.google.com/go/firestore"
    "github.com/gorilla/mux"
)

type UserProfile struct {
    UserID    string `json:"userId"`
    FirstName string `json:"firstName"`
    LastName  string `json:"lastName"`
    PublicBio string `json:"publicBio"`
}

func GetUserProfile(db *firestore.Client) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        vars := mux.Vars(r)
        userID := vars["userID"]
        authUserID := r.Context().Value("authUserID").(string) // authenticated subject

        if userID != authUserID {
            http.Error(w, "forbidden", http.StatusForbidden)
            return
        }

        ctx := r.Context()
        docSnap, err := db.Collection("users").Doc(userID).Get(ctx)
        if err != nil {
            http.Error(w, "unable to retrieve user", http.StatusInternalServerError)
            return
        }
        if docSnap.Data() == nil {
            http.Error(w, "not found", http.StatusNotFound)
            return
        }

        // Explicit projection to avoid Pii Leakage
        safeProfile := UserProfile{
            UserID:    userID,
            FirstName: docSnap.Data()["firstName"].(string),
            LastName:  docSnap.Data()["lastName"].(string),
            PublicBio: docSnap.Data()["publicBio"].(string),
        }

        w.Header().Set("Content-Type", "application/json")
        json.NewEncoder(w).Encode(safeProfile)
    }
}

In this pattern, the code never forwards fields such as email, phone, or passwordHash. Even if the Firestore document contains these keys, they are excluded from the output. This approach aligns with the principle of least privilege and data minimization, reducing the impact of accidental logging or client-side caching of sensitive information.

For list endpoints, apply the same DTO strategy. Iterate over query results and transform each document individually, ensuring no PII slips through due to a missing field filter. Avoid using generic map propagation (e.g., json.NewEncoder(w).Encode(docSnap.Data())) in production handlers, as that directly exposes all stored fields to the client.

Middleware can also enforce field-level policies by inspecting the response writer and redacting sensitive keys before serialization, but the most reliable control is to never include PII in the handler output in the first place. Regular audits of handler code against the defined DTOs help maintain consistency as schemas evolve.