Cross Site Request Forgery in Django with Firestore

Cross Site Request Forgery (CSRF) occurs when an authenticated user is tricked into submitting an unwanted request that executes unintended actions. In a Django application that uses Google Cloud Firestore as a backend, the risk arises from combining Django’s session-based authentication with Firestore operations that are initiated from the client or from insufficiently validated server-side calls.

Django provides built-in CSRF protection via middleware and the {% csrf_token %} template tag for forms that submit to Django views. However, when Firestore is used directly from the client (for example, using the Firebase client SDK) or when Firestore write operations are triggered by Django views without strict origin and referer checks, the boundary between authenticated sessions and Firestore requests can be abused. An attacker can craft a malicious site that causes a logged-in user’s browser to issue Firestore writes or deletes, leveraging the user’s existing session cookies or tokens if the Firestore client is configured with broad permissions.

Another exposure path is server-side Django code that calls Firestore on behalf of the user without validating the request origin or binding the request to a verified user action. If a Django view accepts POST data and directly maps it to Firestore document updates without CSRF verification or strict input validation, an attacker can use forged requests to modify resources they should not access. This is especially relevant when Firestore security rules rely on authentication UID but the request path does not enforce CSRF protections at the web layer.

Additionally, if an application exposes Firestore REST endpoints or uses callable functions that are invoked from the browser without anti-CSRF tokens, the unauthenticated attack surface expands. Even though Firestore enforces its own security rules, those rules assume the request context is trustworthy at the entry point; CSRF undermines that trust by hijacking authenticated sessions to make malicious calls appear legitimate.

To mitigate CSRF when integrating Django with Firestore, enforce CSRF protection at the Django view layer and avoid relying solely on Firestore security rules for request origin validation. Always use Django’s CSRF middleware and ensure that any form submitting to a Django view includes the CSRF token. For client-side Firestore operations, keep sensitive operations behind authenticated Django endpoints rather than allowing direct client writes wherever possible.

Server-side Django view with Firestore write (recommended)

In this example, a Django view processes a form submission, verifies CSRF, authenticates the user, and then writes to Firestore using the server-side Admin SDK. This ensures that Firestore operations originate from trusted server code and are tied to verified user identity.

import os
os.environ.setdefault('GOOGLE_APPLICATION_CREDENTIALS', '/path/to/service-account.json')

from django.shortcuts import render, redirect
from django.views.decorators.csrf import csrf_protect
from google.cloud import firestore
from django.contrib.auth.decorators import login_required

@csrf_protect
@login_required
def update_profile(request):
    if request.method == 'POST':
        # Django verifies CSRF token automatically for POST requests
        display_name = request.POST.get('display_name', '').strip()
        if not display_name:
            return render(request, 'profile.html', {'error': 'Name is required'})
        
        db = firestore.Client()
        user_ref = db.collection('users').document(request.user.id)
        user_ref.update({
            'display_name': display_name,
            'updated_at': firestore.SERVER_TIMESTAMP
        })
        return redirect('profile')
    return render(request, 'profile.html')

Client-side Firestore with anti-CSRF token for sensitive operations

If client-side Firestore is necessary, include an anti-CSRF token (e.g., synchronised from a Django-rendered page) and validate it on the server before performing sensitive writes. This pattern adds a layer of assurance that the request originated from your own forms.

// In your Django template, include a CSRF-derived custom token for Firestore actions
var csrfToken = '{{ csrf_token }}'; // Rendered by Django

// Send this token alongside Firestore operations initiated from the client
async function safeFirestoreUpdate(token, newData) {
  // Validate token with your Django endpoint before proceeding
  const response = await fetch('/api/validate-csrf/', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ csrf_token: token })
  });
  if (!response.ok) throw new Error('CSRF validation failed');

  // Proceed with Firestore update only after validation
  const db = firebase.firestore();
  await db.collection('user_data').doc('doc_id').update(newData);
}

Firestore security rules should complement Django CSRF protections

Ensure Firestore rules require authentication and validate that the requesting user matches the resource owner. While this does not replace CSRF protection, it reduces the impact of a potential CSRF vector by enforcing ownership checks on the server side of Firestore.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

By combining Django’s CSRF middleware, server-side Admin SDK usage, and disciplined client-side patterns, you reduce the risk of CSRF compromising Firestore-backed workflows.