Unreleased episodes, rough cuts, and client feedback are sensitive material. Cuevue is built so that no single mistake exposes them: isolation is enforced by the database rather than by application code, media never sits in a public bucket, and every share link is a revocable credential rather than an unguessable URL.
This page describes the controls that are actually in place today, and is explicit about what we have not done yet.
1. Workspace isolation is enforced by the database
Every multi-tenant table in Cuevue has PostgreSQL Row Level Security enabled, gated by membership checks on the space that owns the row. Access decisions are made by the database on every single query.
Most software answers “whose data is this?” in application code, where one missing filter in one query becomes a cross-customer leak. Cuevue answers it one layer down, so an application bug fails closed instead of leaking.
2. Your media never sits in a public bucket
- All audio, video, and attachments are stored in private Cloudflare R2 storage — never a publicly readable bucket
- Files are served through short-lived presigned URLs generated per request, so there is no permanent link to leak, forward, or scrape
- Storage credentials are server-side only and are never exposed to the browser
- Uploads go directly to storage over TLS using presigned, scoped credentials
3. Share links are revocable credentials
A Cuevue review link is not just a hard-to-guess URL. Each link is a distinct credential you can constrain and withdraw:
- Password protection — optional per link, hashed with PBKDF2-SHA256 at 200,000 iterations with a unique per-link salt and constant-time verification
- Expiry — links can be set to stop working on a date you choose
- Instant revocation — revoking a link cuts access immediately, without affecting any other link
- Download control — reviewers can be limited to streaming only
- Email capture — optionally require reviewers to identify themselves before viewing
- Watermarking — available on Studio plans to make leaked screen captures traceable
Link tokens are stored hashed, so a copy of our database would not yield working links. Link and password checks are also written to take the same amount of time whether or not a link is protected, so response timing cannot be used to fingerprint which links are worth attacking. Every link is rate limited per client and in aggregate.
4. Reviewers get the least access that works
People you send a review link to are never issued a normal login session. They exchange the link for a short-lived, automatically refreshed access ticket scoped to that one version.
Reviewers see only comments explicitly marked public. That filter is applied when data is read, not hidden in the interface — a reviewer cannot reach your team's internal notes by inspecting the page or calling the API directly.
5. Encryption
- In transit: TLS everywhere, with HSTS set to a two-year max-age including subdomains, and submitted to the browser preload list
- At rest: databases and object storage are encrypted at rest by our infrastructure providers
- Connected accounts: OAuth tokens for integrations such as Google, Slack, and YouTube are additionally encrypted by Cuevue with AES-256-GCM under a rotatable key ring, so rotating a key does not invalidate existing data
- Payment details: card data is handled entirely by Stripe. Cuevue never sees or stores card numbers
- Secrets and tokens: all security tokens are generated from a cryptographically secure random source. API keys and review, refresh, and media tokens are stored hashed or as HMACs, never in plaintext
6. Browser and application hardening
- A strict Content Security Policy, with violation reporting enabled. We proxy our own analytics and error reporting through our own domain specifically so the policy never has to be loosened for a vendor
X-Frame-Options: DENY — Cuevue cannot be embedded in another site's frame, which blocks clickjacking- MIME-sniffing disabled, and a referrer policy that stops full URLs leaking to third parties
- A permissions policy that disables geolocation outright and limits camera and microphone to Cuevue itself, for voice notes you record deliberately
- Every signed-in route is marked no-index, so workspace pages never enter a search engine
- Cross-site request forgery protection on state-changing requests
7. Abuse and injection defense
- Every API request is schema-validated at the boundary before it reaches business logic
- Rate limits are applied per endpoint category and fail closed on authentication and billing paths, so an outage cannot become an open door
- Outbound requests — webhooks and integrations — are checked against internal and cloud-metadata address ranges and are not allowed to follow redirects past that check
- All CSV and spreadsheet exports neutralize formula injection, so a comment written by an outside reviewer cannot execute when your team opens the export
- Payment webhooks are signature-verified, and internal scheduled jobs authenticate with constant-time secret comparison
- Bot protection on signup
8. Audit trail and recovery
- Security-relevant actions — sign-in, permission and membership changes, billing changes, file uploads and deletions, integration connections, account deletion — are written to an append-only audit log
- Workspace content changes are recorded in an append-only activity log showing who changed what, when, and the before and after values. It is written from a single code path, so the history cannot diverge
- Databases are backed up daily, compressed, encrypted with AES-256 before leaving our infrastructure, and stored in a separate bucket from application data
9. Account security
- Passkeys: sign in with Face ID, Touch ID, or a hardware key. Passkeys are phishing-resistant — there is no password for an attacker to capture or reuse
- Role-based access: members, admins, and custom roles, with per-project and per-view visibility controls
- Workspace passwords: an optional additional gate on a whole space
- Account deletion: you can delete your account and content from your account settings. See our Privacy Policy for retention details
10. How we test our own security
Cuevue has been through two full internal security audits, in February and July 2026, each covering authentication and authorization, injection, secrets handling, cryptography, access control, and dependencies. Findings are recorded with a disposition, and every fix ships with a regression test so the same class of issue cannot silently return.
The most recent audit found one high-severity issue in outbound webhook delivery. It was fixed and regression-tested before the audit closed. We would rather tell you that than claim we have never found anything.
11. Compliance status
We would rather be precise than impressive. Here is exactly where we stand:
| Item | Status |
|---|
| Encryption in transit and at rest | In place |
| Database-level tenant isolation | In place |
| Audit logging of security events | In place, mapped to SOC 2 CC7.2 |
| Encrypted daily backups | In place |
| Internal security audits | Two completed in 2026 |
| SOC 2 Type II certification | Not certified — controls are SOC 2 aligned |
| Third-party penetration test | Not yet performed |
| GDPR data access and deletion rights | Supported — see Privacy Policy |
If your organization requires a signed data processing agreement or a completed security questionnaire, contact us and we will work through it with you.
12. What Cuevue does not do
Being clear about limits matters as much as listing controls:
- We do not use DRM. Anyone you authorize to watch a cut can record their own screen. Download controls and watermarking make that traceable and inconvenient; they cannot make it impossible. No review platform can
- Review links are shareable by design. By default, anyone holding the link can open it — that is what makes sending a cut to a client simple. The link itself is the credential, so treat it like one. Add a password, an expiry date, or both when the material warrants it
- We do not sell your data, use your content to train AI models, or serve advertising
13. Reporting a vulnerability
If you believe you have found a security issue in Cuevue, please report it to support@cuevue.io with “Security report” in the subject line. Include the steps to reproduce it and what you were able to access.
We aim to acknowledge reports within two business days. Please give us a reasonable window to ship a fix before disclosing publicly, and do not access, modify, or retain data belonging to anyone but yourself while investigating. We will not pursue legal action against researchers who report in good faith and follow these guidelines.