Broken Authentication in Strapi with Firestore

Broken Authentication in a Strapi + Firestore setup often stems from misalignment between Strapi's session/cookie handling and Firestore's security model. Strapi can be configured to use Firestore as a custom database for content storage, but authentication decisions (e.g., JWT validation, session management) must still be enforced by Strapi before data requests reach Firestore. If Strapi endpoints are inadvertently exposed or if custom controllers bypass Strapi's policies, unauthenticated or low-privilege requests may directly invoke Firestore rules, effectively exposing the Firestore instance as an unauthenticated attack surface.

Consider an endpoint like GET /api/users/:id implemented as a custom controller that builds a Firestore query using the request parameter :id without verifying that the requesting user owns that document. If the associated Firestore security rules are misconfigured—such as allowing read access based only on document ID patterns or missing ownership checks—an attacker can enumerate user IDs and read other users' data. This is a Broken Authentication issue (BOLA/IDOR) because the application fails to enforce that a subject can only access resources they own or are explicitly permitted to view.

Another vector involves service accounts or API keys embedded in frontend code or client-side requests. Firestore can allow unauthenticated reads if rules are permissive for testing, and if Strapi does not require authenticated sessions for certain operations, an unauthenticated attacker can leverage these open endpoints to pull data. This maps to the Unauthenticated LLM endpoint detection concept in middleBrick’s LLM/AI Security checks when AI-generated code or prompts inadvertently expose Firestore endpoints; more broadly, it reflects the risk of open access paths in serverless backends. Additionally, if JWT secrets are weak or tokens are not properly validated by Strapi before Firestore interaction, attackers can forge tokens to escalate privileges, aligning with BFLA/Privilege Escalation checks. These patterns highlight why authentication enforcement must be consistent at the application layer (Strapi) regardless of the underlying storage (Firestore).

Remediation centers on ensuring Strapi fully mediates every request before Firestore interaction, and that Firestore rules align with least-privilege principles. Always enforce ownership checks in Strapi controllers and avoid passing raw user input directly to Firestore queries.

Example: Secure user profile endpoint with ownership verification

// src/api/user/controllers/user.js
'use strict';

module.exports = {
  async me(ctx) {
    const userId = ctx.state.user?.id; // authenticated user ID from Strapi auth middleware
    if (!userId) {
      ctx.status = 401;
      return { error: 'Unauthenticated' };
    }

    // Explicitly scope the Firestore query to the requesting user
    const userDoc = await strapi.db.connection.collection('users').doc(userId).get();
    if (!userDoc.exists) {
      ctx.status = 404;
      return { error: 'Not found' };
    }

    ctx.body = userDoc.data();
  },
};

Firestore security rules aligned with Strapi ownership checks

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    // Other collections should enforce ownership or role-based checks similarly
  }
}

In this setup, Strapi’s authentication middleware (e.g., JWT verification) ensures ctx.state.user is trustworthy. The controller then uses that trusted user ID to scope Firestore operations, preventing IDOR. The Firestore rules act as a secondary safeguard, ensuring that even if a request bypasses Strapi (e.g., direct calls to Firestore from an untrusted environment), access is still bounded by authentication and UID matching. This layered approach addresses BOLA/IDOR and supports compliance mappings to OWASP API Top 10 (2023) A01:2023 and A07:2021.

For automated scanning, use the middleBrick CLI to validate these controls: middlebrick scan https://your-strapi.example.com. The tool can detect missing ownership checks and overly permissive rules, reporting findings with severity and remediation guidance. Teams on the Pro plan can enable continuous monitoring to catch regressions early, while the GitHub Action can fail CI/CD pipelines if the security score drops below a chosen threshold.