API Security

NearSync's API layer runs on Supabase Edge Functions (Deno-based V8 isolates). This page covers the network and application security measures that protect the API surface.

CORS Policy

All Edge Functions enforce origin-locked Cross-Origin Resource Sharing (CORS):

• Only requests from configured production domains are accepted
• Development origins (localhost) are allowed in development environments only
• Non-matching origins are rejected - the API never responds with a wildcard (*) CORS header
• Each BYOK deployment configures its own allowed origins matching its deployed domains

This prevents malicious websites from making API requests using a user's authenticated session.

Rate Limiting

Per-IP, per-endpoint rate limiting is enforced on all Edge Functions. Limits are tuned based on the sensitivity and expected usage patterns of each endpoint category.

Rate Limit Tiers

Endpoint Category	Requests per Minute	Rationale
User creation / account operations	5/min	Prevents account enumeration and brute-force signup abuse
Email sending	10/min	Prevents spam and email abuse
Staff invitations	10/min	Prevents invitation flooding
Booking operations	10/min	Prevents calendar abuse
Messaging (WhatsApp)	20/min	Balances real-time communication needs with abuse prevention
AI chat	30/min	Higher limit for interactive AI usage; cost-controlled by provider quotas
Payment operations	10/min	Prevents payment manipulation attempts
Invite validation	10/min	Prevents brute-force token guessing
Default (all other endpoints)	60/min	Standard operational rate for dashboard interactions

Rate Limit Behavior

• Rate limits are tracked per IP address and per endpoint
• When a limit is exceeded, the API returns 429 Too Many Requests with a Retry-After header
• Rate limit buckets are cleaned every 60 seconds to free expired entries
• Rate limiting operates at the Edge Function isolate level

note

Edge Function rate limiting provides application-layer abuse protection. For volumetric DDoS mitigation, NearSync relies on Vercel's edge network and Supabase's infrastructure-level protections.

Authentication Middleware

Every API request passes through authentication middleware before reaching the endpoint handler:

1. The middleware extracts the JWT from the Authorization header
2. The token is validated server-side against Supabase Auth (signature + expiry check)
3. If the token is invalid or expired, the request is rejected with 401 Unauthorized
4. If the token is valid, the authenticated user context is established for the request

A small set of public endpoints (booking, invite acceptance, signup, document verification) bypass authentication to support pre-login flows.

Input Validation

SQL Injection Prevention

All database queries use the Supabase client library, which generates parameterized queries. No raw SQL is constructed from user input in the application code.

XSS Prevention

• Email templates apply HTML escaping to all user-provided values before rendering
• The React frontend provides built-in XSS protection for rendered content
• Content-Type validation routes requests to appropriate handlers (form-encoded content is routed to the telephony handler; JSON to the main handler)

Request Body Handling

• Edge Functions parse request bodies with error handling
• Malformed JSON requests are caught and rejected gracefully
• Unexpected content types are rejected rather than silently processed

API Key Management

Server-Side Key Storage

API keys for third-party services (AI providers, telephony, messaging, payments) are stored in one of two locations:

• Edge Function secrets - for keys needed during server-side processing
• Database (global_settings table) - for keys that are configurable per-organization

Keys are never bundled into client-side JavaScript. The frontend calls Edge Functions, which retrieve keys from server-side storage at runtime.

BYOK Key Isolation

In BYOK deployments, all API keys are stored in the client's own database or their own Edge Function secrets. NearSync infrastructure has zero access to these keys.

Secret Rotation

• Database-stored keys can be rotated by updating the configuration in the admin dashboard
• Edge Function secrets can be rotated via the Supabase dashboard or CLI
• OAuth tokens (Google, Microsoft) use automatic refresh flows with no long-lived tokens stored

Webhook Security

NearSync receives webhooks from several third-party services:

Provider	Validation Method
WhatsApp (Meta)	Token validation against stored configuration
Telephony provider	Content-Type validation (form-encoded detection)
OAuth callbacks	PKCE (Proof Key for Code Exchange) for Google, Microsoft, and Salesforce

OAuth flows use PKCE to prevent authorization code interception. Temporary PKCE sessions are stored in the database and automatically cleaned after completion.

TLS

All production traffic uses HTTPS, enforced by both Vercel (frontend) and Supabase (backend):

• Frontend assets served over HTTPS via Vercel's edge network
• Database connections encrypted with TLS 1.2+
• Edge Function invocations over HTTPS
• No unencrypted HTTP traffic in production

Edge Function Sandbox

Supabase Edge Functions run in Deno-based V8 isolates, providing:

• Sandboxed execution - each function invocation runs in an isolated environment
• No filesystem access - functions cannot read or write to the host filesystem
• Network restrictions - outbound requests are limited to configured destinations
• Automatic security patches - Supabase manages the runtime environment

Related Pages

• Authentication - JWT validation and session management
• Row-Level Security - database-level access enforcement beyond the API layer
• Security Overview - how API security fits into the overall architecture