Broken Authentication in Loopback with Firestore

Loopback is a widely used Node.js framework for building APIs, and it often integrates with Google Cloud Firestore as a persistence layer. When authentication controls are weak or misconfigured in a Loopback application using Firestore, the API’s identity and authorization boundaries can be bypassed, leading to Broken Authentication. This typically occurs when session management, token validation, or access control rules are not enforced consistently between the Loopback layer and Firestore security rules.

One common pattern is for Loopback controllers to retrieve user identity from a decoded JWT or session and then directly reference user IDs to query Firestore. If the controller does not re-validate ownership or authorization on each request, an attacker can manipulate the user identifier — for example, by changing numeric IDs in query parameters — to access another user’s documents. Because Firestore security rules may not be aligned with these authorization checks in Loopback, the API may return data that should be restricted.

Additionally, weak password storage in user documents (e.g., storing plaintext passwords or using weak hashing) can expose credentials. If Loopback’s User model does not enforce strong hashing with salts and does not require multi-factor authentication for sensitive operations, attackers can compromise accounts through credential stuffing or brute-force attacks. Misconfigured Firestore rules that allow public read or write access to user collections further amplify the impact, enabling attackers to enumerate valid user IDs or exfiltrate authentication-related data.

Another vector involves token handling. If Loopback issues long-lived access tokens without refresh token rotation or proper revocation mechanisms, stolen tokens can be reused. Combined with overly permissive Firestore rules that allow document access based solely on UID parameters provided by the client, this can lead to horizontal privilege escalation. For example, an authenticated user could modify the request UID to access another user’s private records, and Firestore may return the data if rules do not enforce server-side ownership checks.

These issues are especially relevant in unauthenticated or black-box scans, where tools like middleBrick test the attack surface without credentials. middleBrick’s Authentication and BOLA/IDOR checks can identify whether authentication is properly enforced and whether users can access other users’ data through ID manipulation. Its LLM/AI Security checks also verify whether authentication mechanisms are exposed to prompt injection or abuse in any AI-assisted components.

To remediate Broken Authentication in a Loopback application using Firestore, enforce strict server-side authorization, use secure token handling, and align Firestore security rules with Loopback access controls. Below are concrete code examples and configurations.

1. Enforce Ownership Checks in Loopback Controllers

Always resolve the current user from the request context and validate ownership before querying Firestore. Do not rely on client-supplied identifiers alone.

const {AuthBindings} = require('@loopback/authentication');
const {repository} = require('@loopback/repository');
const {inject} = require('@loopback/core');
const {Firestore} = require('@google-cloud/firestore');

const firestore = new Firestore();

class UserProfileController {
  constructor(
    @repository(UserRepository) public userRepository: UserRepository,
  ) {}

  async getProfile(@inject(AuthBindings.CURRENT_USER) currentUser: User) {
    const userDoc = await firestore.collection('users').doc(currentUser.id).get();
    if (!userDoc.exists) {
      throw new HttpErrors.NotFound('Profile not found');
    }
    return userDoc.data();
  }
}

2. Use Firestore Security Rules for Server-Side Authorization

Define rules that enforce ownership and role-based access. Ensure rules do not allow public read/write and require authentication.

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

3. Secure Password Storage and Multi-Factor Authentication

Use strong hashing (bcrypt) for passwords and require MFA for sensitive operations. Store only hashed passwords in Firestore.

const bcrypt = require('bcrypt');
const saltRounds = 12;

async function hashPassword(plainPassword) {
  return await bcrypt.hash(plainPassword, saltRounds);
}

async function verifyPassword(plainPassword, hashedPassword) {
  return await bcrypt.compare(plainPassword, hashedPassword);
}

4. Short-Lived Access Tokens with Refresh Token Rotation

Configure Loopback’s authentication component to issue short-lived access tokens and rotate refresh tokens. Implement token revocation on logout.

module.exports = {
  accessToken: {
    ttl: 15 * 60, // 15 minutes
  },
  refreshToken: {
    ttl: 7 * 24 * 60 * 60, // 7 days
    reuseRejected: false,
  },
};

5. Validate and Sanitize Input to Prevent ID Manipulation

Use Loopback’s validation and interceptors to ensure request parameters conform to expected formats and cannot be abused for IDOR.

const {validate} = require('@loopback/repository');

UserProfileController.prototype.validateUserId = function(userId) {
  if (!userId || typeof userId !== 'string' || !/^[a-zA-Z0-9_-]+$/.test(userId)) {
    throw new Error('Invalid user ID');
  }
};

By combining these practices — server-side user resolution, strict Firestore rules, secure credential storage, and robust token management — the risk of Broken Authentication in Loopback with Firestore is significantly reduced.