Security & Data Protection

All network traffic between clients, APIs, and sub-processors is encrypted via TLS 1.3. PFS (ECDHE key exchange) ensures that session keys cannot be derived from the server's long-term private key — past sessions remain confidential even if a private key is later compromised.

HTTP requests are redirected to HTTPS across all web-facing surfaces. HSTS (HTTP Strict Transport Security) headers instruct browsers to refuse non-HTTPS connections for the domain and subdomains.

Permitted cipher suites include TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, and TLS_AES_128_GCM_SHA256. Weak cipher suites (RC4, 3DES, NULL) are explicitly disabled. Cipher suite selection is inherited from Netlify (edge) and Supabase (database).

Database connections use PgBouncer via Supabase (transaction mode, port 6543) with TLS enforced on all pooled connections. Direct connections for migrations use port 5432 with TLS required. No plaintext database connections are permitted.

All data stored in Supabase (PostgreSQL on AWS us-east-1) is encrypted at rest using AES-256, managed by AWS at the storage layer. This covers all tables, indexes, and backup snapshots.

Automated daily backups are encrypted at rest using the same AES-256 standard. Backups are stored separately from the primary volume and retained for 30 days.

Voice call recordings and transcripts processed by VAPI are encrypted at rest on GCP infrastructure. Recordings are automatically purged after 90 days. Clients may request earlier deletion.

API keys, integration credentials, and service-role keys are stored as encrypted environment variables in Netlify and Railway. Credentials are never committed to source control. Secret rotation is performed manually and tracked.

Every table containing customer data enforces RLS policies that restrict reads and writes to the requesting organization's data. Organization scope is validated at the database layer — no application-level workaround can bypass it. Cross-tenant data leakage is structurally prevented.

Server-side functions that require elevated privileges use the service_role client only after validating the caller's organization membership in the API route itself. Service-role keys are never exposed to browser clients.

All authenticated sessions use short-lived JWTs issued by Supabase Auth. Tokens are signed (HS256 / RS256), validated server-side on every API request, and automatically refreshed. Expired or tampered tokens are rejected.

Three access roles: PM Admin (full access to their organization's data, settings, and team management), Contractor (job-specific access — sees only jobs assigned to them, via a separate portal), and Viewer (read-only, planned). Role claims are embedded in JWTs and verified on every protected route.

Multi-factor authentication (TOTP-based) is required on all Dimora AI infrastructure accounts including Supabase, Railway, Netlify, GitHub, Cloudflare, and AWS. MFA is recommended (and UI-prompted) for customer accounts, though not currently enforced.

All production system access is reviewed quarterly. Accounts are audited for continued need. Stale accounts and unused service credentials are revoked. This applies to both internal team access and sub-processor API keys.

The Dimora AI web application is served via Netlify's global edge network. Netlify provides L3/L4 DDoS mitigation and automatic traffic scrubbing at the edge layer. No direct-origin exposure for web traffic.

API endpoints enforce rate limits to prevent abuse and brute-force attempts. Authentication endpoints (login, password reset) apply stricter per-IP limits. Rate limit violations return 429 responses and are logged.

All web responses include the Strict-Transport-Security header with a minimum 1-year max-age directive and includeSubDomains. This prevents SSL-stripping attacks and forces HTTPS-only connections from compliant browsers.

HTTP responses include: Content-Security-Policy (restrict script/frame sources), X-Frame-Options: DENY (clickjacking prevention), X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and Permissions-Policy (disable camera/microphone/geolocation in web app). Headers configured in next.config.ts.

Supabase database instances run in isolated VPCs on AWS. Direct database access is restricted to allowlisted connection sources. Connection pooler (PgBouncer) is the only publicly exposed database endpoint.

All API routes validate request body structure, data types, and value ranges before processing. Unexpected fields are stripped. Requests failing validation return 400 with structured error responses — no raw error strings that could expose internal state.

All database interactions use Supabase's PostgREST client or parameterized SQL via the Supabase SDK. Raw string interpolation in SQL is not used anywhere in the codebase. Supabase's prepared statement handling structurally prevents SQL injection.

React's JSX templating automatically HTML-encodes dynamic content before rendering, preventing reflected XSS. dangerouslySetInnerHTML is not used in the application. Transcript and message content is always rendered through React's encoding pipeline.

CSP headers restrict which scripts, styles, frames, and connections the browser permits. Inline scripts are restricted. External script sources are allowlisted to known providers (Supabase, Clarity, GA4). CSP violations are surfaced in browser console.

The application codebase contains no use of eval(), Function(), or setTimeout/setInterval with string arguments. All n8n automation Code nodes use explicit JavaScript — no dynamic code construction from user-supplied input.

Outbound HTTP requests from server-side routes validate destination URLs against an allowlist. Internal network addresses (169.254.x.x, 10.x.x.x, 127.x.x.x) are blocked to prevent server-side request forgery.

Invite tokens and one-time credentials use atomic check-and-consume database operations to prevent time-of-check-to-time-of-use race conditions. Tokens are single-use and invalidated immediately on consumption.

Primary database and auth platform. Hosted on AWS us-east-1 (N. Virginia, USA). Supabase holds SOC 2 Type II certification (audited annually). Physical security, environmental controls, and logical access controls at the infrastructure layer are covered by Supabase's compliance posture.

Supabase runs on AWS us-east-1 (N. Virginia). AWS maintains ISO 27001, SOC 1/2/3, and PCI DSS certifications. Physical security of data centers — including access controls, CCTV, biometric authentication, and 24/7 security — is AWS's responsibility and is audited annually.

n8n workflow automation runs on Railway (United States). Railway holds SOC 2 certification. Execution environments are tenant-isolated. No persistent guest personal data is stored in Railway — data passes through during workflow execution.

Web application frontend deployed on Netlify's global CDN. Netlify provides DDoS protection, TLS termination, and automated SSL certificate management. Build artifacts are isolated per deployment. Production environment variables are encrypted at rest.

Dependabot is enabled on the GitHub repository. It automatically scans npm dependencies against known CVE databases (GitHub Advisory Database, NVD) and opens pull requests for vulnerable or outdated packages.

Critical severity CVEs are assessed immediately upon Dependabot alert or public disclosure. Patches are applied and deployed within 7 calendar days. High severity CVEs are addressed within 30 days.

npm audit is run weekly as part of the development process. Results are reviewed and tracked. Low/medium severity issues are batched for resolution monthly unless they have a viable exploitability path.

Dimora AI has not yet commissioned an external penetration test. Annual third-party penetration testing will be commissioned when operationally warranted by data volume or customer requirement. Enterprise customers may request a customer-funded penetration test — contact security@dimora.ai to discuss.

Internal security reviews of RLS policies, API route authorization, and access controls are conducted on a regular basis. The most recent review (March 2026) addressed 75+ findings across 10 security domains — all critical and high issues were remediated in commit cad3221.

All authentication events are logged: sign-in attempts (success and failure), password reset requests, token refresh, MFA events, and admin actions. Logs are accessible in the Supabase dashboard and retained per Supabase's retention policy.

PostgREST API calls and edge function executions are logged with timestamps, request identifiers, and response status codes. Slow query logging is enabled. Logs are used to detect unusual query patterns, data exports, or access anomalies.

All n8n workflow executions (Guesty webhooks, VAPI events, upsell triggers, AI processing runs) are logged with full execution traces. Logs are retained for 30 days minimum and used to audit AI decision paths and identify processing errors.

Railway and Netlify provide deployment and error alerts. Critical workflow failures (Guesty webhook misses, Supabase connection failures, VAPI processing errors) surface in real-time via error alerting to the operations team.

Production logs are accessible only to authorized Dimora AI personnel. Clients may request log extracts related to their organization's activity for compliance or incident investigation purposes — contact security@dimora.ai.

Each team member is granted only the access required for their role. Production database access is limited to personnel who require it for operations or incident response — not the entire team by default. Access grants are reviewed quarterly.

External contractors engaged for development or support work do not receive direct production database access. Contractors work against development or staging environments. Any production access requires documented justification and is logged.

All production database access is logged via Supabase audit logs. Access by any account (including admin accounts) is timestamped and traceable. Logs are reviewed as part of the quarterly access review.

Dimora AI does not currently perform formal background checks given the 2-person team structure. This is disclosed honestly. As the team scales and customer data volumes grow, background screening will be incorporated into the hiring process.

All team members and contractors with any access to customer data are bound by confidentiality obligations in their employment or contractor agreements. These obligations survive termination.