Clinical Horizon handles sensitive healthcare infrastructure data.
We take the security of this platform seriously and appreciate responsible disclosure.

• All protected routes require a valid Firebase session token.
• Firestore Security Rules enforce server-side role checks — the frontend role gating is a UX layer only.
• The hardcoded Master Admin bypass (admin@bedmgmt.com / MasterAdmin2026!) must be removed or disabled before any production deployment. It exists only for local development convenience. See AuthContext.jsx.
• Google OAuth is enabled. Revoke OAuth tokens in the Firebase Console if a breach is suspected.

Never commit real credentials.

All VITE_ prefixed variables are embedded in the client bundle at build time and are visible to anyone who inspects the JavaScript files. This is standard practice for Firebase web apps — security is enforced by Firestore Security Rules and Firebase App Check, not by keeping keys secret.

Recommended hardening:

1. Restrict your Firebase API key in the Google Cloud Console to only your deployed domain.
2. Enable Firebase App Check with reCAPTCHA v3 or Device Check.
3. Write strict Firestore Security Rules that validate request.auth.uid and custom claims.
4. Enable Email Enumeration Protection in Firebase Authentication settings.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    // Users can only read/write their own profile
    match /users/{uid} {
      allow read, update: if request.auth != null && request.auth.uid == uid;
      allow create: if request.auth != null;
    }

    // Admins and superadmins can read all user docs
    match /users/{uid} {
      allow read: if request.auth != null
        && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role
           in ['admin', 'superadmin'];
    }

    // All other collections — deny by default
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Please do not open a public GitHub issue for security vulnerabilities.

1. Email: shaurya@example.com (replace with your real address)
2. Include: description of the vulnerability, reproduction steps, potential impact, and (if possible) a suggested fix.
3. You will receive a response within 48 hours.
4. Once confirmed and patched, the vulnerability will be disclosed publicly with credit to the reporter (unless you prefer to remain anonymous).

1. Vulnerability is reported privately.
2. We reproduce and assess severity (CVSS score).
3. A patch is developed on a private branch.
4. The fix is merged and a new release is tagged.
5. A public advisory is published via GitHub Security Advisories.

Thank you for helping keep Clinical Horizon and its users safe.