===============================================================================
CBA UTILS PROJECT MANAGEMENT - SECURITY & AUTHENTICATION NOTICE
===============================================================================
Last Updated: November 2026
Document Version: 1.0
Target Platform: CBA Utils Project Management Suite
-------------------------------------------------------------------------------
1. OVERVIEW & SECURITY PHILOSOPHY
-------------------------------------------------------------------------------
CBA Utils Project Management ("CBA Utils") is engineered with a multi-layered,
zero-trust security model designed to safeguard project data, proprietary documents,
user credentials, and internal communications.
Security is enforced at every tier of the application stack—from edge proxying
and server-side authorization guards to Firebase security rules and encrypted
cloud infrastructure.
-------------------------------------------------------------------------------
2. THREE-LAYER AUTHENTICATION & ACCESS CONTROL
-------------------------------------------------------------------------------
CBA Utils enforces defense-in-depth through three distinct security layers to
prevent unauthorized access, privilege escalation, and resource ID probing:
LAYER 1: EDGE PROXY (src/proxy.ts)
- Serves as the front-line optimistic gatekeeper for incoming Web requests.
- Validates session cookie presence (`__session`) prior to routing requests.
- Automatically rejects unauthenticated API attempts with HTTP 401 Unauthorized
and redirects browser requests to `/login?next=...`.
LAYER 2: SERVER POLICY GUARDS (src/lib/auth/guards.ts & policies.ts)
- Serves as the authoritative security boundary for all server-side logic
(Server Components, Next.js Server Actions, and API Route Handlers).
- Performs cryptographic session cookie verification (`verifySessionCookie`).
- Evaluates resource-level policies prior to data execution:
* requireProjectAccess(id, level): Enforces owner, team member, or staff rules.
* requireFileAccess(id): Validates uploader identity and project access.
- Fails securely by throwing typed AuthErrors that render generic 404 pages,
preventing malicious actors from confirming the existence of private IDs.
- Caches permissions per-request (`React.cache`) to prevent redundant database hits.
LAYER 3: FIREBASE CLOUD SECURITY RULES (firestore.rules & storage.rules)
- Form the ultimate hard boundary for direct client SDK database and storage access.
- Restricts direct read/write operations exclusively to verified, authenticated
users with staff custom claims.
-------------------------------------------------------------------------------
3. IDENTITY & STAFF AUTHORIZATION POLICIES
-------------------------------------------------------------------------------
Authentication identity is maintained strictly via verified server-side session cookies.
- CUSTOM CLAIMS & PRIVILEGES:
Access privileges are tied to Firebase Auth Custom Claims (`staff: true` or
`admin: true`). Claims are set programmatically via administrative channels.
- DOMAIN RESTRICTIONS:
Access is restricted by default to verified email addresses belonging to authorized
organizational domains (e.g., `cbamoney.com`).
- KILL SWITCH CAPABILITY:
Accounts explicitly assigned `{ staff: false }` are immediately blocked from all
system access regardless of domain or past activity.
- SESSION ISOLATION:
Server Actions extract user identity exclusively from the verified server session
token. Client-supplied `userId` inputs are never trusted or accepted.
-------------------------------------------------------------------------------
4. DATA ENCRYPTION & STORAGE PROTOCOLS
-------------------------------------------------------------------------------
- DATA IN TRANSIT:
All traffic between client browsers, Next.js application servers, and Firebase
cloud services is enforced over HTTPS utilizing TLS 1.3 / TLS 1.2 encryption.
Unencrypted HTTP requests are automatically upgraded.
- DATA AT REST:
All persistent data stored within Google Cloud Firestore, Firebase Realtime
Database, and Cloud Storage for Firebase is encrypted at rest using AES-256 encryption.
- DIRECT FILE UPLOADS:
File uploads execute directly from the client browser to Cloud Storage via
resumable, authorized channels. Binary payloads are never buffered through
serverless execution memory, reducing payload exposure and service timeouts.
-------------------------------------------------------------------------------
5. INFRASTRUCTURE & ISOLATION
-------------------------------------------------------------------------------
- HOSTING ENVIRONMENT:
Hosted on Google Cloud Platform / Firebase App Hosting serverless infrastructure,
providing automated scaling, DDoS protection, and containerized isolation.
- NO-CACHE SENSITIVE ENDPOINTS:
All authorized API routes and server responses carry standard non-caching headers
(`Cache-Control: private, no-store`) to prevent caching of sensitive data in
downstream proxies or public nodes.
- SERVICE FILE ISOLATION:
Backend services (`src/lib/services/*`) are marked as `server-only` and operate
strictly behind policy guards to ensure non-authenticated invocation is impossible.
-------------------------------------------------------------------------------
6. USER RESPONSIBILITIES & REPORTING
-------------------------------------------------------------------------------
Authorized users are responsible for maintaining account security:
- Do not share session credentials or authorization tokens.
- Immediately report lost devices or suspicious activity to system administrators.
SECURITY CONTACT & VULNERABILITY DISCLOSURE:
To report security vulnerabilities or request access audits, please contact:
Security Operations Team
Email: security@cbautils.com
===============================================================================