Security overview

TrendSuite runs on Vercel (edge runtime and serverless functions) and Supabase (managed PostgreSQL and authentication). Both providers hold SOC 2 Type II certifications and publish transparency reports. We do not operate any self-managed servers; the infrastructure layer is fully managed by providers whose security posture we have evaluated.

Application deployments are immutable and go through a CI gate (typecheck, lint, unit tests, build) on every push. Production deployments require the gate to pass. Rollbacks to any prior deployment are available instantly via Vercel without a re-deploy.

In transit.All traffic between clients and TrendSuite servers is encrypted with TLS 1.3. We enforce HTTPS on every route via Vercel’s edge network, with HSTS preload enabled so that browsers never make a plain-HTTP request even on first visit.

At rest — database. All data at rest in Supabase Postgres is encrypted at the storage layer by the underlying cloud provider. Sensitive social-account tokens additionally receive a dedicated application-layer encryption pass (described below) before they are written to the database.

At rest — application layer. OAuth access tokens and refresh tokens for connected social accounts receive an additional layer of AES-256-GCM encryption applied at the application layer before being written to the database. The ENCRYPTION_KEY used for this is stored as a Vercel environment secret and is never committed to source control. Even in the event of a database dump, social tokens are not recoverable without the application-layer key.

Key management. The application-layer encryption key is held as a managed environment secret with access restricted to the deployment platform. Should a key need to be rotated — for example, in response to a suspected exposure — our incident response procedures cover re-encrypting the affected data. A fixed, automated rotation cadence is on our security roadmap rather than an operational guarantee today.

Identity management is handled by Supabase Auth. Passwords are hashed using bcrypt with a work factor tuned to current hardware capability. Email verification is mandatory before an account becomes active; unverified accounts cannot access any data-bearing endpoints.

Multi-factor authentication (MFA) via TOTP is available on all account tiers. We recommend but do not yet mandate MFA for Agency accounts; mandatory MFA for Agency-tier accounts is on the roadmap.

Google OAuth is supported as an alternative to password-based login. OAuth tokens from Google are used solely to identify the user; we do not request write access to any Google service at the authentication step.

Row-Level Security (RLS) is enforced at the PostgreSQL layer on every user-scoped table. This means that even if an application bug were to issue a query without a user filter, the database would return only the rows that the authenticated user is permitted to see. RLS is not an optional enhancement — it is the primary access control boundary.

For Agency accounts, brand workspaces are scoped to explicit brand-member relationship rows. A user cannot access a brand workspace they are not explicitly a member of, regardless of application-layer logic. Agency workspace isolation is covered by automated tests that run on every CI push.

The entire codebase is written in TypeScript with strict mode enabled. The use of as any, @ts-ignore, and @ts-expect-error is prohibited by project policy — a CI lint check enforces this. The goal is that type errors are eliminated at compile time, not suppressed.

ESLint is configured with Next.js recommended rules plus security-oriented rules (no eval, no dangerouslySetInnerHTML without review). Sentry is instrumented for both server-side errors and client-side exceptions. All unhandled errors surface in real time to the engineering team.

HTTP security headers are set on every response, including Strict-Transport-Security (HSTS with preload), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. A Content Security Policy is currently deployed in report-only (monitoring) mode while its directives are finalised; it will be promoted to enforcing ahead of the public launch.

All sub-processors that handle personal data are listed in the Privacy Policy sub-processors table, along with their certifications and the data shared with each. We require sub-processors that handle EEA/UK personal data to operate under Standard Contractual Clauses or equivalent transfer mechanisms.

We evaluate sub-processor security posture before onboarding them and review it annually or upon significant changes to their terms. Providers with SOC 2 Type II certifications are preferred; alternatives must demonstrate equivalent controls.

Application errors and performance anomalies are monitored in real time via Sentry. Vercel provides access logs and edge function execution traces. Alert thresholds are configured for error rate spikes, latency regressions, and unusual traffic patterns.

An on-call rotation is being established for the period surrounding public launch. Prior to launch, the engineering team monitors alerts directly. Our incident response playbook covers detection, containment, eradication, recovery, and post-mortem steps. Incidents affecting user data trigger the breach notification procedures described in the Privacy Policy.

We welcome responsible disclosure from security researchers. If you have found a vulnerability in any production-exposed TrendSuite surface, we want to know about it.

• CVEs publicly attributed to TrendSuite: none to date.
• Last third-party penetration test: scheduled Q4 2026 (pre-launch).
• SOC 2 Type I target: approximately 6 months post-public launch.