Enterprise-grade protection for financial data

All sensitive data stored by Quadesto is encrypted at rest using AES-256-GCM, the same encryption standard used by banks and government agencies. Each credential record is encrypted with a unique random initialization vector (IV) and includes an authentication tag to detect tampering. The encryption key is stored as an environment variable on the server, never in the database.

Data files uploaded to the platform are stored in encrypted object storage. Temporary caches use encrypted Redis instances with automatic TTL-based expiry, ensuring that cached data does not persist beyond its useful lifetime.

All data in transit between clients and Quadesto servers is encrypted using TLS 1.3 with modern cipher suites. HTTP Strict Transport Security (HSTS) headers ensure that browsers only communicate over HTTPS, and certificate transparency logs provide an additional layer of verification. Connections to external data providers are also encrypted, and the platform verifies TLS certificates before establishing any outbound connection.

Quadesto uses Supabase Auth for user authentication, issuing signed JWTs (JSON Web Tokens) on login. Tokens are short-lived and refreshed automatically. Sessions are managed server-side with secure, httpOnly cookies to prevent client-side token theft via XSS.

Every database table has Postgres Row-Level Security (RLS) policies enforced at the database layer. This means that even if an application-level vulnerability were exploited, the database itself prevents any user from reading or writing another tenant's data. RLS policies are not optional middleware — they are enforced by Postgres on every query, regardless of how the query is issued.

Team workspaces support role-based access control. Workspace owners can invite team members with specific permission levels. Member permissions determine access to workspace settings, data source configuration, and credential management. Permission checks are enforced server-side on every API route, not just in the UI.

When you connect an external data provider — such as a financial API, database, or webhook — your credentials are encrypted immediately upon receipt using AES-256-GCM and stored in an encrypted credential vault. The plaintext credential exists in server memory only for the duration of the encryption operation.

Credentials are decrypted only server-side when needed to fetch data on your behalf. They are never sent to the browser, never included in API responses, and never logged. The client application has no mechanism to retrieve the raw credential value — it can only reference credentials by ID.

To prevent server-side request forgery (SSRF), all outbound requests initiated by the platform are validated against a deny list of private IP ranges, loopback addresses, link-local addresses, and known internal hostnames. DNS resolution is performed and checked before the HTTP request is made, preventing DNS rebinding attacks where a hostname initially resolves to a public IP but later resolves to an internal address.

Quadesto runs on dedicated infrastructure using a self-hosted Supabase deployment. This means your data is not stored on shared multi-tenant database clusters managed by a third party. The Postgres instance, authentication service, and object storage are all deployed on infrastructure controlled by Quadesto.

All API endpoints are protected by Redis-backed rate limiting using sliding window counters. Rate limits survive container restarts and work correctly across multiple application instances. AI-powered endpoints, such as analysis and chat, have separate per-user rate limits to prevent credit abuse and ensure fair usage across all accounts.

The infrastructure is deployed on European data centers with automated backups and monitoring. Container orchestration handles automatic restarts and health checks, ensuring high availability without manual intervention.

Every HTTP response from Quadesto includes a comprehensive set of security headers. Strict-Transport-Security (HSTS) ensures browsers only connect over HTTPS. Content-Security-Policy (CSP) restricts which scripts, styles, and resources can load, mitigating cross-site scripting (XSS) attacks. X-Content-Type-Options prevents MIME type sniffing. X-Frame-Options and frame-ancestors directives prevent clickjacking by controlling which sites can embed Quadesto pages — with an exception for the embed feature, which allows framing only for published views.

Referrer-Policy is set to restrict referrer information sent to external sites, and Permissions-Policy disables access to browser features that Quadesto does not use, such as camera, microphone, and geolocation.

All API error responses are sanitized before being sent to the client. Database constraint names, internal table structures, stack traces, and implementation details are stripped from error responses and logged server-side only. This prevents information leakage that could help an attacker understand the internal architecture. Input validation is performed server-side on all API routes, and user-provided content is sanitized before storage and rendering.

Quadesto does not sell, share, or monetize your data. Your financial data is yours. The platform processes your data only to provide the visualization, analysis, and collaboration features you use. Data fetched from external providers is cached with configurable TTL (time-to-live) values to reduce unnecessary API calls, and cached data is automatically purged when the TTL expires.

You retain full control over your data at all times. You can delete individual data sources, workspaces, or your entire account. When you delete data, it is removed from the database and any associated caches. Deleted data is not retained for analytics or training purposes.

The platform is designed with GDPR awareness. Data is processed and stored in European data centers. Users can export their data and request complete account deletion. No tracking pixels or third-party analytics services are used to profile user behavior within the application.