Cross Site Request Forgery in Gorilla Mux with Firestore

Cross Site Request Forgery (CSRF) occurs when an attacker tricks a victim’s browser into making an unwanted authenticated request to a target application. When using Gorilla Mux with Firestore, the risk arises from a mismatch between Firestore’s security model and HTTP handler design. Firestore rules rely on authenticated requests carrying user identity (typically via an ID token), but handlers implemented with Gorilla Mux may inadvertently rely on cookies or session tokens without enforcing anti-CSRF protections for state-changing HTTP methods.

In a typical setup, a client authenticates to your backend (e.g., via session cookies or an ID token in an Authorization header) and then interacts with Firestore through backend handlers routed by Gorilla Mux. If a handler for a POST, PUT, or DELETE route does not validate the origin of the request or require a same-site token, an attacker can craft a malicious site that causes the victim’s browser to invoke those routes. Because Firestore operations from the backend execute with the backend’s credentials (service account) or passed user credentials, the backend may perform privileged Firestore writes without ensuring the end-user intended the action. This becomes more pronounced when CORS is misconfigured, allowing cross-origin requests that bypass browser same-origin policies, and when handlers do not validate the Referer or Origin headers or require CSRF tokens for unsafe methods.

Gorilla Mux does not enforce CSRF protections by default; it simply matches routes and invokes handlers. Therefore, developers must explicitly add CSRF defenses such as same-site cookies, anti-CSRF tokens in forms or headers, and strict CORS policies. Additionally, Firestore security rules should be designed to require authentication and to validate request context, but they cannot mitigate CSRF at the HTTP layer where the malicious request originates. The combination of Gorilla Mux routing and Firestore backend operations thus exposes a classic CSRF surface when state-changing endpoints lack proper origin verification and token validation.

To secure Gorilla Mux routes that perform Firestore operations, implement CSRF protections at both the HTTP handler layer and the Firestore rules layer. Below are concrete code examples demonstrating these measures.

1. Gorilla Mux handler with CSRF token validation

Use a middleware that validates a CSRF token for unsafe methods. Store the token in a signed, same-site cookie and require it in a header for state-changing requests.

import (
	"net/http"
	"github.com/gorilla/mux"
	"github.com/gorilla/csrf"
)

func main() {
	r := mux.NewRouter()
	// Set a same-site cookie-based CSRF token for forms and AJAX.
	csrfMiddleware := csrf.Protect([]byte("32-byte-long-auth-key-here1234"),
		csrf.Secure(false), // set true in production with HTTPS
		csrf.HttpOnly(false),
		csrf.SameSite(csrf.SameSiteStrictMode),
	)

	// Example protected write endpoint
	writeHandler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		docID := mux.Vars(r)["docID"]
		ctx := r.Context()

		// Assume Firestore client is initialized globally as firestoreClient
		ref := firestoreClient.Collection("items").Doc(docID)
		_, err := ref.Update(ctx, []firestore.Update{
			{Path: "data", Value: "updated"},
		})
		if err != nil {
			http.Error(w, "failed to update", http.StatusInternalServerError)
			return
		}
		w.WriteHeader(http.StatusOK)
	})

	r.Handle("/items/{docID}", csrfMiddleware(writeHandler)).Methods("POST", "PUT", "DELETE")
	http.Handle("/", r)
	http.ListenAndServe(":8080", nil)
}

The csrf middleware sets a token in a same-site cookie; your frontend must read this token (e.g., from a meta tag or cookie) and include it in the X-CSRF-Token header for unsafe methods. This prevents cross-origin sites from executing authenticated requests via embedded forms or JavaScript.

2. Firestore security rules requiring authentication and origin checks

While CSRF defenses live at the HTTP layer, Firestore rules should enforce authentication and, where appropriate, restrict operations based on request context. Note that Firestore rules cannot inspect HTTP Origin/Referer directly, so backend validation remains essential.

Example Firestore rule requiring authentication and scoped write paths:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /items/{document=**} {
      allow read: if request.auth != null;
      allow write: if request.auth != null && request.auth.token.trusted == true;
    }
  }
}

On the backend, ensure that the Firestore client is initialized with end-user credentials (e.g., using ID tokens from authenticated sessions) rather than a privileged service account when user-specific security is required. Validate the user’s ID token on each request and pass a constrained Firebase token or use the user’s UID in Firestore paths to enforce ownership-based rules.

3. CORS and cookie settings

Configure CORS to restrict origins and avoid wildcard allowances. Set SameSite and Secure cookie attributes to reduce CSRF feasibility. For SPAs, use strict CORS origins and consider anti-CSRF tokens in headers rather than relying solely on cookies.

// Example CORS middleware for Gorilla Mux
func corsMiddleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		w.Header().Set("Access-Control-Allow-Origin", "https://your-app.com")
		w.Header().Set("Access-Control-Allow-Methods", "GET, POST, OPTIONS")
		w.Header().Set("Access-Control-Allow-Headers", "Authorization, Content-Type, X-CSRF-Token")
		w.Header().Set("Access-Control-Allow-Credentials", "true")
		if r.Method == "OPTIONS" {
			w.WriteHeader(http.StatusOK)
			return
		}
		next.ServeHTTP(w, r)
	})
}