Enterprise-Grade Security Architecture

1. Infrastructure Security

1.1 Hosting Architecture

CloudReef operates on a distributed, multi-layer infrastructure:

All infrastructure providers maintain independently audited compliance certifications. CloudReef does not operate bare-metal servers.

1.2 Network Security

• DDoS Protection: Cloudflare enterprise-grade DDoS mitigation absorbs volumetric, protocol, and application-layer attacks at the edge before traffic reaches application servers
• Web Application Firewall (WAF): Cloudflare WAF with managed rulesets filters malicious requests including SQL injection attempts, cross-site scripting payloads, and known exploit patterns
• Bot Management: Automated traffic classification distinguishes legitimate users from credential-stuffing bots, scrapers, and vulnerability scanners
• DNS Security: DNSSEC-signed zones prevent DNS spoofing and cache poisoning attacks
• Rate Limiting: Edge-level rate limiting prevents brute-force authentication attempts and API abuse

1.3 TLS Configuration

All connections to CloudReef services are encrypted in transit:

• Protocol: TLS 1.2 and TLS 1.3 (TLS 1.0 and 1.1 disabled)
• HSTS: HTTP Strict Transport Security enforced with max-age=31536000; includeSubDomains
• Certificate Management: Automated certificate provisioning and renewal via Cloudflare (no manual certificate handling)
• Cipher Suites: Modern cipher suites only. ECDHE key exchange, AES-256-GCM and ChaCha20-Poly1305 encryption
• Forward Secrecy: All connections use ephemeral key exchange, ensuring past sessions cannot be decrypted if long-term keys are compromised

2. Data Encryption

2.1 Encryption in Transit

All data transmitted between clients, edge network, application servers, and database is encrypted using TLS. This includes:

• Browser to Cloudflare edge (TLS 1.3)
• Cloudflare to Vercel application (TLS 1.2+)
• Application to Supabase database (TLS 1.2+, enforced by Supabase)
• Application to Stripe payment API (TLS 1.2+)
• Supabase Realtime WebSocket connections (WSS)

2.2 Encryption at Rest

• Database: PostgreSQL data files encrypted at rest using AES-256 via AWS EBS volume encryption. Encryption keys are managed by AWS Key Management Service (KMS) with automatic key rotation
• Object Storage: Files stored in Supabase Storage (S3-compatible) are encrypted at rest using server-side encryption (SSE-S3, AES-256)
• Backups: Database backups are encrypted using the same AES-256 encryption as primary storage

3. Authentication & Session Management

3.1 Authentication Architecture

CloudReef uses Supabase Auth, which is built on top of GoTrue, an open-source JWT-based authentication system:

• Password Hashing: User passwords are hashed using bcrypt with a work factor of 10 (adaptive cost function)
• JWT Tokens: Short-lived access tokens (1 hour expiry) with secure refresh token rotation
• Session Storage: Tokens stored in secure, HttpOnly cookies managed by Supabase SSR middleware
• Token Refresh: Automatic transparent token refresh on every request via Next.js middleware. Users experience uninterrupted sessions while tokens rotate frequently
• Sign-Out: Server-side session invalidation with client-side token removal and redirect

3.2 Session Security Controls

• Automatic Session Expiry: Idle sessions expire based on JWT TTL configuration
• Active Session Monitoring: Auth state changes are monitored in real-time via Supabase onAuthStateChange listener
• Concurrent Session Handling: New sessions automatically invalidate stale state
• Account Deactivation: Staff accounts can be deactivated (is_active = false), immediately preventing authentication even with valid credentials

4. Authorization & Access Control

4.1 Role-Based Access Control (RBAC)

CloudReef implements a seven-tier role hierarchy enforced at both application and database layers:

Role assignment is stored at the database level in the users table with a PostgreSQL enum constraint, preventing invalid role values.

4.2 Three-Layer Authorization Enforcement

Layer 1. Middleware (Route Level)

Next.js middleware intercepts every request. Unauthenticated requests to protected routes are redirected to the login page. Public routes (/login, /qr/*) bypass authentication requirements.

Layer 2. Application (Component Level)

Dashboard layout components verify the authenticated user's role against the requested route using the canAccessRoute() permission check. Unauthorized access renders an access-denied screen with appropriate messaging rather than exposing any protected data.

Layer 3. Database (Row Level Security)

PostgreSQL Row Level Security policies enforce data isolation at the query level. Every database query is automatically filtered by the authenticated user's resort_id, derived from their Supabase Auth UID. This ensures that even if application-level checks are bypassed, the database itself prevents cross-tenant data access.

5. Multi-Tenant Data Isolation

5.1 Architecture

CloudReef uses a shared-database, shared-schema multi-tenant architecture with Row Level Security (RLS) enforcing tenant boundaries:

• Every data table includes a resort_id foreign key referencing the resort_settings table
• Every database query is scoped to the authenticated user's resort via RLS policies
• Cross-tenant data access is architecturally impossible. The database engine itself rejects unauthorized queries before results are returned

5.2 Row Level Security Policy Pattern

All tenant-scoped tables implement the following RLS policy:

CREATE POLICY "Resort data access" ON [table_name]
  FOR ALL USING (
    resort_id IN (
      SELECT resort_id FROM users WHERE auth_id = auth.uid()
    )
  );

This policy:

• Executes on every SELECT, INSERT, UPDATE, and DELETE operation
• Derives the authorized resort_id from the authenticated user's Supabase Auth UID
• Filters results before they leave the database engine
• Cannot be bypassed by application-layer code

5.3 Protected Tables

Row Level Security is enforced on all 17 data tables:

resort_settings, users, rooms, guests, bookings, menu_categories, menu_items, orders, order_items, inventory, activities, activity_bookings, invoices, conversations, messages, notifications, error_logs

5.4 Cascading Data Integrity

Foreign key constraints with ON DELETE CASCADE ensure that when a resort is removed, all associated data is automatically and atomically deleted:

resort_settings (parent)
  ├── users
  ├── rooms
  ├── guests
  ├── bookings
  ├── menu_categories
  ├── inventory
  ├── activities
  ├── invoices
  ├── conversations
  ├── notifications
  └── error_logs

Critical business constraints prevent accidental data loss:

• ON DELETE RESTRICT on guests -> bookings (cannot delete a guest with active bookings)
• ON DELETE RESTRICT on rooms -> bookings (cannot delete a room with active bookings)
• ON DELETE RESTRICT on menu_items -> order_items (cannot delete menu items with existing orders)

6. Database Security

6.1 Query Safety

• Parameterized Queries: All database interactions use the Supabase client library, which parameterizes all query values. No raw SQL strings are constructed from user input, eliminating SQL injection as an attack vector.
• Schema Validation: Database columns enforce type constraints, check constraints, and unique constraints at the PostgreSQL level
• Referential Integrity: Foreign key constraints maintain data consistency across all related tables

6.2 Schema Constraints

6.3 Indexes & Performance

Strategic database indexes prevent slow queries from becoming denial-of-service vectors:

• Composite indexes on (resort_id, created_at) for time-series queries
• Composite indexes on (resort_id, status) for filtered views
• Lookup indexes on authentication identifiers (auth_id)
• Full-text indexes on searchable fields (last_name, first_name, email)

6.4 Backups & Recovery

• Automated Backups: Daily point-in-time recovery backups managed by Supabase (AWS)
• Retention: Backup retention per Supabase plan (7-30 days)
• Encryption: Backups encrypted at rest using AES-256
• Recovery Testing: Point-in-time recovery capability to any second within the retention window

7. Application Security

7.1 Framework Security

• Server Components by Default: Next.js 14 App Router uses React Server Components, ensuring sensitive logic executes on the server and is never sent to the client
• Environment Variable Isolation: Server-side secrets (service role keys, API credentials) are never prefixed with NEXT_PUBLIC_ and cannot be accessed from client-side code
• Automatic CSRF Protection: Next.js server actions include built-in CSRF token validation
• TypeScript Strict Mode: All code is written in TypeScript with strict mode enabled, catching type-related security issues at compile time

7.2 Input Handling

• Form Validation: All form inputs are validated on both client and server sides
• Data Truncation: Error messages truncated to 2,000 characters, stack traces to 5,000 characters, preventing log injection and storage abuse
• File Upload Processing: Uploaded files are resized and re-encoded to JPEG format, stripping potentially malicious metadata (EXIF data, embedded scripts)

7.3 Error Handling

• Error Boundaries: React error boundaries on every route prevent unhandled errors from crashing the application or exposing stack traces to end users
• Graceful Degradation: Every component implements loading, empty, and error states. Users never see raw error output or blank screens
• Error Classification: Automated error classification system categorizes errors by severity (error, warning, info) and source (client, server, API, database, auth)
• Error Deduplication: In-memory deduplication with a 5-second sliding window prevents log flooding from repeated errors
• Silent Failure on Logging: Error logging itself fails silently to prevent cascading failures

8. Real-Time Security

CloudReef uses Supabase Realtime for live data updates (new orders, booking changes, notifications). Real-time channels are secured through:

• Authenticated Connections: WebSocket connections require valid JWT tokens
• Resort-Scoped Filters: Real-time subscriptions include resort_id filters, ensuring clients only receive events for their own property
• Row Level Security: RLS policies apply to real-time change events. Unauthorized data changes are never broadcast
• Channel Cleanup: Subscriptions are properly cleaned up on component unmount, preventing memory leaks and stale connections

9. Payment Security

CloudReef integrates with Stripe for payment processing:

• No Card Storage: CloudReef never stores, processes, or transmits raw credit card numbers. All payment data is tokenized by Stripe
• PCI DSS Compliance: Payment processing is handled entirely by Stripe (PCI DSS Level 1 certified), the highest level of payment security certification
• Payment Status Only: CloudReef stores only payment status indicators (pending, paid, refunded) and Stripe reference identifiers. Never raw financial data
• Server-Side Processing: All payment operations occur server-side through Stripe's authenticated API

10. Monitoring & Incident Response

10.1 Real-Time Error Monitoring

CloudReef includes a built-in diagnostic console that provides:

• Live Error Streaming: Errors are captured and displayed in real-time via WebSocket connections
• Multi-Source Capture: Automatic capture of unhandled JavaScript errors, unhandled promise rejections, console errors, database errors, API errors, and authentication errors
• Known Issue Pattern Matching: An integrated error knowledge base automatically matches errors against 13 known patterns, providing human-readable explanations and one-click remediation actions
• Error Resolution Tracking: Errors can be marked as resolved, with automatic cleanup of resolved logs after 30 days

10.2 Error Sources Captured

10.3 Incident Response

• Detection: Automated real-time error detection with severity classification
• Notification: In-app notification system alerts property managers of critical errors
• Triage: Error book pattern matching provides immediate context and suggested actions
• Resolution: One-click automated fixes for common issues (session refresh, cache clearing, page reload)
• Communication: Security incidents are investigated and communicated to affected property operators within 24 hours

11. Access Control for Public Interfaces

11.1 QR Code System

CloudReef provides QR code-based ordering for restaurant tables and hotel rooms:

• Hash-Based Access: QR codes use unique alphanumeric identifiers. Guests access menus by scanning codes, not by authenticating
• Read-Only Public Access: QR code endpoints provide read-only access to menu data only. No guest personal data, booking information, or operational data is accessible through QR interfaces
• Booking Verification: Room QR codes verify guest identity against active bookings before allowing room-service orders
• Scoped Data: QR endpoints only expose menu categories, menu items, and table/room assignments. Never staff data, financial records, or other guest information

12. Notification Security

• Resort-Scoped: Notifications are filtered by resort_id at both the database level (RLS) and the application level (query filter)
• Deduplication: Notification creation includes deduplication logic to prevent duplicate alerts
• Database Triggers: Notification creation for bookings and activity sign-ups is handled by PostgreSQL SECURITY DEFINER triggers, ensuring consistent behavior regardless of client context
• Real-Time Delivery: Notifications are delivered via authenticated WebSocket channels with resort-scoped filters

13. Compliance & Certifications

13.1 Infrastructure Compliance

13.2 Data Protection Practices

• GDPR: Data processing activities documented, DPAs available, data subject rights supported, sub-processor list maintained
• Data Minimization: Only data necessary for platform operation is collected and processed
• Purpose Limitation: Data is used only for the purposes described in this documentation and the Privacy Policy
• Storage Limitation: Retention periods defined for all data categories with automated purge mechanisms

14. Security Contact