Cursor + Firebase + Vercel Security Blueprint

Share

To secure a Cursor + Firebase + Vercel stack, you need to: (1) replace test-mode Firestore rules with production rules that check authentication and ownership, (2) configure Firebase Storage rules to restrict file access, (3) store the Firebase Admin SDK service account key in Vercel environment variables (never client-side), (4) create a .cursorignore file to prevent AI from accessing service account files, and (5) review AI-generated code for missing auth checks and overly permissive queries. This blueprint covers Firestore rules, Storage rules, and credential management across all three platforms.

Setup Time2-3 hours

TL;DR

Firebase with Cursor requires careful security rules configuration. The main risks are overly permissive Firestore rules (common in AI-generated code) and exposed service account keys. Write proper security rules before going live, use Firebase Auth for authentication, store the Firebase Admin SDK key in Vercel environment variables, and never expose it client-side.

Platform Guides & Checklists

      Cursor Security Guide



      Firebase Security Guide



      Vercel Security Guide



      Pre-Launch Checklist

Stack Overview

Firebase provides database, authentication, and storage in one platform. When combined with Cursor for development and Vercel for hosting, you get a powerful stack with specific security considerations:

ComponentRoleSecurity Focus
CursorAI code editorReview generated Firebase rules
FirebaseDatabase + Auth + StorageSecurity rules, service account protection
VercelHostingEnvironment variables, API routes

Part 1: Firestore Security Rules Firebase

Understanding the Default Danger Firebase

Firebase projects often start with test mode rules that allow all access. AI tools like Cursor might generate code that assumes these permissive rules:

DANGEROUS: Test mode rules (never use in production)
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;  // Anyone can read/write everything!
    }
  }
}

Secure Firestore Rules Firebase

Replace with rules that require authentication and check ownership:

Secure Firestore rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Users can only access their own user document
    match /users/{userId} {
      allow read, update: if request.auth != null
        && request.auth.uid == userId;
      allow create: if request.auth != null;
    }

    // Posts are public to read, but only author can modify
    match /posts/{postId} {
      allow read: if true;
      allow create: if request.auth != null;
      allow update, delete: if request.auth != null
        && request.auth.uid == resource.data.authorId;
    }

    // Private data requires authentication
    match /private/{userId}/{document=**} {
      allow read, write: if request.auth != null
        && request.auth.uid == userId;
    }
  }
}

AI code risk: Cursor may generate Firestore queries without checking if your rules allow them. Always verify that your security rules match your application's access patterns.

Firebase Storage Rules Firebase

Also secure your Firebase Storage:

Storage security rules
rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    // User-specific uploads
    match /users/{userId}/{allPaths=**} {
      allow read: if request.auth != null;
      allow write: if request.auth != null
        && request.auth.uid == userId
        && request.resource.size < 5 * 1024 * 1024; // 5MB limit
    }

    // Public assets (read-only)
    match /public/{allPaths=**} {
      allow read: if true;
      allow write: if false; // Only through Admin SDK
    }
  }
}

Part 2: Firebase Credentials Firebase Vercel

Client vs Admin Credentials Firebase

Credential TypePurposeExposure
Firebase Config (apiKey, etc.)Client-side SDKSafe for public (rules protect data)
Service Account JSONAdmin SDK (bypasses rules)Never expose publicly
Client-side Firebase config (safe to expose)
// This config is designed for client-side use
const firebaseConfig = {
  apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
  authDomain: process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN,
  projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
  storageBucket: process.env.NEXT_PUBLIC_FIREBASE_STORAGE_BUCKET,
  messagingSenderId: process.env.NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID,
  appId: process.env.NEXT_PUBLIC_FIREBASE_APP_ID
};

Admin SDK Setup (Server-Side Only) Vercel

Server-side Admin SDK (API route or server component)
// lib/firebase-admin.ts
import { initializeApp, getApps, cert } from 'firebase-admin/app';
import { getFirestore } from 'firebase-admin/firestore';

const serviceAccount = JSON.parse(
  process.env.FIREBASE_SERVICE_ACCOUNT_KEY || '{}'
);

if (!getApps().length) {
  initializeApp({
    credential: cert(serviceAccount),
  });
}

export const adminDb = getFirestore();

Security Checklist

Pre-Launch Checklist for Cursor + Firebase + Vercel

Firestore security rules updated from test mode

Storage security rules configured

Service account key in Vercel env vars only

Service account key not in git repository

Firebase Auth configured with allowed domains

Security headers in vercel.json

.cursorignore excludes sensitive files

Admin SDK only used in API routes/server code

Rules tested with Firebase Emulator

Alternative Stack Configurations

Cursor + Supabase + Vercel Swap Firebase for Supabase. Different security model with PostgreSQL RLS instead of Firestore rules.

      Cursor + React + Firebase
      Client-side focused React app without Vercel. Same Firebase security, different hosting considerations.


      Bolt.new + Firebase
      Swap Cursor for Bolt.new. Same Firebase/Vercel config, different AI code review approach.

Is the Firebase apiKey safe to expose?

Yes, the client-side Firebase config (including apiKey) is designed to be public. Security comes from your Firestore and Storage rules, not from hiding these keys. The apiKey just identifies your project.

How do I test Firestore rules before deploying?

Use the Firebase Emulator Suite locally, or the Rules Playground in the Firebase Console. Test with different auth states and document scenarios to verify rules work correctly.

When should I use the Admin SDK?

Use the Admin SDK in server-side code (Vercel API routes or server components) for operations that need to bypass security rules, like admin dashboards, background jobs, or operations that affect multiple users.

Using Firebase with Cursor?

Scan your app for security rule issues and misconfigurations.

Start Free Scan
Security Blueprints

Cursor + Firebase + Vercel Security Blueprint