Api Key Exposure in Echo Go with Firestore

When building HTTP services in Go using the Echo framework and integrating Google Cloud Firestore, developers often store Firestore credentials as environment variables or configuration values. If these values are inadvertently exposed through logs, error messages, or insecure HTTP responses, the API key or service account key becomes accessible to unauthorized parties. This exposure commonly occurs when debugging endpoints or verbose error handlers return internal configuration details to the client.

Echo routes that return Firestore client initialization details or propagate raw configuration errors can leak sensitive data. For example, a handler that opens a Firestore client and returns a collection listing without proper access controls might expose metadata that includes project identifiers. Combined with weak authentication around administrative endpoints, this creates a path where an attacker can enumerate projects or harvest credentials from error traces.

The risk is compounded when Firestore security rules rely on authentication that is not rigorously enforced at the API layer. If an Echo endpoint does not validate incoming tokens against Firestore’s rules before performing reads or writes, an attacker who obtains an API key may escalate access to sensitive documents. This aligns with BOLA/IDOR patterns where broken object level authorization allows traversal across project resources.

middleBrick scans identify this risk by testing unauthenticated endpoints that interact with Firestore, checking for information leakage in responses and validating that authentication is enforced before data access. Findings include references to the OWASP API Security Top 10 and mapping to compliance frameworks such as SOC2 and GDPR, highlighting the need to protect credentials and enforce strict rule sets.

To mitigate exposure, initialize Firestore clients outside request handlers and avoid returning configuration details in HTTP responses. Use structured error handling that masks internal paths and keys, and enforce Firestore security rules with validated authentication tokens on every request.

// Safe Firestore initialization and usage in Echo
package main

import (
	"context"
	"github.com/labstack/echo/v4"
	"cloud.google.com/go/firestore"
	"google.golang.org/api/option"
	"os"n")

var db *firestore.Client

func init() {
	ctx := context.Background()
	// Use Application Default Credentials or a service account key file
	// Store the key path via environment variable, never in code
	keyPath := os.Getenv("FIRESTORE_KEY_PATH")
	client, err := firestore.NewClient(ctx, "your-project-id", option.WithCredentialsFile(keyPath))
	if err != nil {
		panic(err) // handled at startup, not per request
	}
	db = client
}

func getData(c echo.Context) error {
	ctx := c.Request().Context()
	iter := db.Collection("sensitive").Where("owner", "==", c.Param("userID")).Documents(ctx)
	defer iter.Stop()

	var results []map[string]interface{}
	for {
		doc, err := iter.Next()
		if err != nil {
			// Do not expose internal details
			return c.JSON(500, map[string]string{"error": "internal server error"})
		}
		if doc == nil {
			break
		}
		results = append(results, doc.Data())
	}
	return c.JSON(200, results)
}

func main() {
	e := echo.New()
	e.GET("/data/:userID", getData)
	e.Start(":8080")
}

This pattern ensures the Firestore client is reused, credentials are not logged, and errors do not reveal stack traces or configuration. Combine this with Firestore security rules that validate request.auth and restrict reads to owned documents to enforce BOLA/IDOR protections.

middleBrick’s CLI can validate that endpoints do not leak credentials by running middlebrick scan <url> and reviewing findings related to Data Exposure and Authentication. The dashboard tracks these checks over time, and the Pro plan enables continuous monitoring so new exposures are flagged as soon as they appear.