Security Overview
NearSync enforces security at multiple layers, from the network edge to individual database rows. This page summarizes the security architecture and threat model. Detailed documentation for each layer is linked below.
Defense-in-Depth Layers
Security is enforced at six layers, each operating independently so that a failure in one layer does not compromise the others:
1. Network Layer
CORS policies restrict which origins can call backend APIs. Rate limiting protects against abuse on a per-IP, per-endpoint basis. All traffic is encrypted with TLS 1.2+.
See API Security for details.
2. Authentication Layer
All non-public API endpoints require a valid JWT. Sessions are managed via Supabase Auth with configurable expiry. Multi-factor authentication (TOTP) is supported and can be required per-organization. Cross-domain sessions use chunked HTTP cookies for seamless navigation between NearSync subdomains.
See Authentication for details.
3. Authorization Layer
Role-based access control (RBAC) defines what each user can see and do. System roles provide granular access, from Admin - the highest role with platform access - down to read-only viewer. Permissions are checked both client-side (navigation gating, component visibility) and server-side (RLS policies).
See RBAC & Permissions for details.
4. Data Layer
PostgreSQL Row-Level Security (RLS) policies enforce data isolation at the database level. In the managed multi-tenant model, RESTRICTIVE org_id policies ensure that no query can access data belonging to another organization - regardless of application logic. In the BYOK model, each client has a fully isolated database.
See Row-Level Security for details.
5. Application Layer
Input validation, parameterized queries (preventing SQL injection), HTML escaping in email templates (preventing XSS), and API key isolation protect against application-level attacks.
See API Security for application-layer details.
6. Infrastructure Layer
NearSync runs on infrastructure provided by vendors with SOC 2 Type II certification:
- Supabase - database, authentication, edge functions, file storage
- Vercel - frontend hosting, CDN, SSL termination, DDoS mitigation
Both platforms provide automatic security patches, encrypted secrets storage, and network-level protections.
Beyond hosting, NearSync engages a small number of processors to deliver specific features: AI providers (Google Vertex/Gemini, OpenAI, Anthropic) and Tavily for web search performed on your behalf; Resend for transactional email; Twilio and LiveKit for voice; Meta for WhatsApp Business messaging; Recall.ai for meeting recording and transcription; Firebase Cloud Messaging for mobile push; Stripe and Razorpay for payments; Sentry for error monitoring.
Integrations you connect yourself — CRM, project, accounting, calendar and storage services — are different: you hold the account and instruct the exchange, so those providers are not NearSync sub-processors. Exchange-rate tables are pulled from ExchangeRate-API and, for the UAE, the Central Bank of the UAE table via AllRatesToday; those are public feeds that receive no customer data, so they are data sources, not sub-processors. The authoritative and current list is the sub-processor table in the Data Processing Agreement.
Threat Model Summary
| Threat | Mitigation |
|---|---|
| Cross-tenant data access | Every table carrying org_id has RLS enabled. Isolation is enforced either by a RESTRICTIVE org_isolation policy or by an org-scoped policy being the only permissive one on the table; both are verified by query and by an automated isolation suite |
| Unauthorized API access | JWT validation on all non-public endpoints; expired/invalid tokens rejected |
| Privilege escalation | RBAC with server-side enforcement via RLS; no client-side-only permission checks for data access |
| SQL injection | Parameterized queries via Supabase client library; no raw SQL in application code |
| XSS | HTML escaping in email templates; React's built-in XSS protection for rendered content |
| API abuse | Per-IP, per-endpoint rate limiting with configurable thresholds |
| Credential theft | API keys stored server-side (database or edge function secrets); MFA available for user accounts |
| Data exfiltration (BYOK) | Zero persistent database access post-provisioning; Sentinel returns metadata only |
Data Classification
NearSync handles several categories of data, each with appropriate access controls:
| Category | Examples | Protection |
|---|---|---|
| PII | User emails, names, phone numbers | RLS-restricted to organization; cross-org isolation enforced |
| Financial | Invoice amounts, payment records, expenses | RLS-restricted; payment processing delegated to certified providers |
| Communications | Chat messages, WhatsApp messages, emails | RLS-restricted to organization |
| Documents | Contracts, uploads, PDFs | RLS-restricted; signed URLs with expiry for storage access |
| Authentication | Passwords, sessions, MFA secrets | Managed by Supabase Auth; not accessible to application code |
| Configuration | System manifest, feature flags, API keys | RLS-restricted to organization; API keys encrypted at rest |
| Audit | Admin actions, workflow logs | Append-only; scoped to organization |
Monitoring and Incident Response
- Error tracking via Sentry across all three applications (admin dashboard, client portal, marketing website)
- Audit logging records admin actions with timestamps and actor identity
- Workflow audit logs record automation execution steps and outcomes
- Alerting configured for application error thresholds
Compliance
- GDPR-ready configuration with privacy URL, terms URL, DPA contact, and GDPR mode flags in the system manifest
- Data export available for managed clients within 30 days of request
- BYOK clients own all data and manage compliance independently
- Standard Data Processing Agreement available for enterprise managed deployments
Security Audit History
August 2026 — full backend audit
A complete audit of the production database, its row-level security, grants, functions and storage buckets. Findings were verified against production rather than inferred, and all of them are closed:
- Contract signature rows were readable without authentication, exposing signer details and the tokens used by the public signing flow. The policy is removed.
- Two storage buckets holding HR documents and client project files were public. Both are private, and access is by short-lived signed URL.
- The audit trail could be modified by the organisation it recorded. Audit tables are now append-only.
- The anonymous role held write grants on every table, and could execute most database functions. Both are revoked; anonymous access is limited to reads on genuinely public content, and to the small set of functions the public policies themselves evaluate.
- Vault-held secrets are encrypted at rest and readable only by administrators.
Verified as part of the same audit: no table carrying org_id runs without RLS, and the
HRMS estate is org-fenced throughout.
Earlier audit
An earlier audit covered 12 areas:
- JWT authentication middleware on all API endpoints
- CORS locked to production domains (no wildcards)
- AI API keys removed from client-side bundles
- Authorization headers on all authenticated requests
- RLS enabled on all tables (including 7 that were previously unprotected)
- Hardcoded admin references replaced with role-based checks
- Schema validation and audit
- API key fallback paths removed
- HTML escaping in email templates
- Per-endpoint rate limiting
- Dependency audit across all packages
- Debug logging removed from production builds
Automated tests cover tenant isolation, gateway authorisation and the RLS helpers. The suite carries a known set of pre-existing failures unrelated to security, so the meaningful gate is that isolation and authorisation tests pass, which they do.
Section Contents
- Authentication - JWT, MFA, sessions, cross-domain auth
- RBAC & Permissions - roles, permissions, module gating
- Row-Level Security - database-level data isolation
- API Security - CORS, rate limiting, input validation