SalesSheet takes security seriously. From server-side AI processing to Content-Security-Policy headers, here is an overview of the measures protecting your data -- written for both non-technical users who want reassurance about their CRM data safety and technical administrators who need to understand the security architecture.
This article covers every layer of SalesSheet's production security stack, including CSP headers, Row Level Security policies, API key management, encryption options, data residency, compliance posture, and audit logging. If you are evaluating SalesSheet for your organization's security requirements, this is your comprehensive reference.
Server-Side AI Processing
API Key Security
All AI API keys (OpenAI, Anthropic, and any other AI provider credentials) are stored exclusively on the server within Supabase Edge Functions. These keys are never transmitted to or accessible from your browser. Even if someone inspects the client-side JavaScript, views network requests, or has physical access to a user's device, they cannot extract AI service credentials. The Edge Functions act as a secure proxy between your browser and the AI providers, ensuring that all AI requests are authenticated server-side.
For Enterprise plan customers, SalesSheet supports Bring Your Own Key (BYOK) configuration. You can provide your own OpenAI or Anthropic API keys, which are stored in an encrypted vault within your Supabase project. BYOK keys are encrypted at rest using AES-256 and are only decrypted within the Edge Function runtime during active requests. This means your AI usage is billed directly to your own provider account, and SalesSheet never has plaintext access to your keys outside of request processing.
Content-Security-Policy Headers
CSP Configuration
SalesSheet serves strict Content-Security-Policy headers on every page. These headers instruct your browser to only load scripts, stylesheets, fonts, and other resources from explicitly approved domains. Any attempt to inject unauthorized third-party scripts -- whether through cross-site scripting (XSS), compromised browser extensions, or man-in-the-middle attacks -- is blocked by the browser before the malicious code can execute.
The CSP policy includes directives for script sources, style sources, image sources, connection sources, and frame ancestors. SalesSheet's CSP configuration blocks inline script execution (except for specifically hashed inline scripts), prevents the use of eval(), and restricts connections to the SalesSheet API, Supabase, and approved AI provider endpoints. This defense-in-depth approach means that even if an attacker finds a way to inject HTML into a page, the browser itself will refuse to execute any unauthorized code.
Row Level Security (RLS)
Database-Level Access Control
SalesSheet uses Supabase's Row Level Security (RLS) policies to enforce data access controls directly at the database level. RLS ensures that every database query is filtered by the authenticated user's organization ID and role. This means that even if an API endpoint had a bug that failed to check permissions in application code, the database itself would prevent a user from reading or modifying data belonging to another organization.
RLS policies are defined for every table in the database: contacts, deals, activities, notes, emails, and custom fields. Each policy verifies that the requesting user belongs to the same organization as the data they are attempting to access. For team-level permissions, additional policies check the user's role (Admin, Manager, or Member) to determine whether they can view, edit, or delete specific records. These policies run on every query, including those made through the real-time subscription system, so live updates are also subject to access control.
Rate Limiting
API Rate Limits
All SalesSheet API endpoints are rate-limited to prevent abuse, protect against automated attacks, and ensure consistent performance for all users. Rate limits are applied per-user and per-endpoint, with different thresholds for read operations (higher limits) and write operations (lower limits). If a user exceeds the rate limit, subsequent requests receive a 429 status code with a Retry-After header indicating when they can resume.
AI-related endpoints have separate, more conservative rate limits to protect against excessive token consumption. These limits are generous enough for normal usage but prevent runaway scripts or compromised accounts from consuming excessive resources. Enterprise plan customers can request adjusted rate limits if their workflows require higher throughput.
Authentication
PKCE Authentication Flow
SalesSheet uses PKCE (Proof Key for Code Exchange) authentication via Supabase Auth. PKCE is a modern, secure login flow designed specifically for browser-based applications where a client secret cannot be safely stored. It protects against authorization code interception attacks by requiring a cryptographic proof that the client requesting an access token is the same client that initiated the login flow.
Session tokens are stored securely in the browser and automatically refreshed before expiration. SalesSheet does not use long-lived tokens or store passwords locally. All authentication traffic is encrypted via HTTPS, and session cookies are marked as Secure, HttpOnly, and SameSite to prevent cross-site request forgery (CSRF) attacks.
Encryption
Data Encryption at Rest and in Transit
All data stored in SalesSheet's database is encrypted at rest using AES-256 encryption, which is the standard used by financial institutions and government agencies. This means that even if the underlying storage media were physically accessed, the data would be unreadable without the encryption keys.
All data in transit between your browser and SalesSheet's servers is encrypted using TLS 1.2 or higher. This includes API requests, real-time subscription data, file uploads, and AI chat interactions. SalesSheet enforces HTTPS on all endpoints and redirects any HTTP requests to HTTPS automatically. HSTS (HTTP Strict Transport Security) headers are set with a one-year max-age to ensure browsers always connect over HTTPS.
Data Residency and Compliance
SalesSheet's infrastructure runs on cloud providers with data centers in multiple regions. By default, data is stored in US-based data centers. Enterprise plan customers can request data residency in specific geographic regions (United States, European Union, or Asia-Pacific) to comply with local data protection regulations such as GDPR or data sovereignty requirements.
SalesSheet's security practices align with industry standards for SaaS applications handling business data. The platform implements controls consistent with SOC 2 Type II requirements, including access controls, change management, incident response procedures, and regular security assessments. For customers in regulated industries, SalesSheet can provide detailed security documentation and participate in vendor security assessments upon request.
Audit Logging
Every significant action in SalesSheet is recorded in an audit log, including user logins, data modifications, permission changes, AI interactions, and administrative actions. Audit logs capture the user who performed the action, the timestamp, the affected record, and the nature of the change (including before and after values for data modifications).
Administrators can access audit logs from Settings > Security > Audit Log. Logs can be filtered by user, action type, date range, and record type. For compliance and incident investigation purposes, audit logs are retained for 12 months on the Pro plan and 24 months on the Enterprise plan. Enterprise customers can also configure audit log exports to external SIEM (Security Information and Event Management) systems for centralized monitoring.
Testing and Monitoring
Continuous Security Monitoring
Over 375 automated tests run before every deployment, covering authentication flows, RLS policy enforcement, API endpoint security, and data validation. These tests ensure that security controls are not accidentally weakened by code changes. The test suite includes specific tests that attempt to access data across organization boundaries, escalate privileges, and inject malicious input, verifying that all defenses hold.
In production, Sentry monitors for errors in real-time and alerts the engineering team to any anomalies. Web Vitals tracking ensures that performance stays consistent, which can also indicate security issues (such as a DDoS attack causing latency spikes). SalesSheet's uptime and incident history are publicly available, and users are notified of any security-relevant incidents through in-app notifications and email.
What This Means for You
- Your data stays private: Server-side processing, RLS policies, and encryption ensure your data is accessible only to authorized users in your organization
- Proactive protection: Automated monitoring, 375+ tests, and real-time error tracking catch issues before they affect you
- Enterprise-grade security: The same techniques used by banks and healthcare applications, including AES-256 encryption, PKCE authentication, and strict CSP headers
- Full audit trail: Every action is logged, giving you complete visibility into who did what and when
- Compliance-ready: Data residency options, audit log retention, and security documentation support your organization's regulatory requirements