Security

EvoViral is operated by R7AD, a sole proprietorship in Markham, Ontario, Canada. Security is built into the way the product handles data: the fewest privileges that work, isolation between customers and signed, verified integrations. This page describes the protections that are actually in place — and, just as importantly, the ones that are not yet in place.

All traffic is served over HTTPS/TLS, and we send an HSTS header (max-age=63072000; includeSubDomains; preload) with upgrade-insecure-requests in the content security policy, so browsers refuse to downgrade to plain HTTP.

Sign-in is handled by Supabase Auth, with optional Google and Apple social sign-in. Session cookies are set HttpOnly, Secure in production and SameSite=Lax, and there is no browser-side Supabase client, so scripts on the page cannot read the session. New and reset passwords are checked against Pwned Passwords using a k-anonymity range query (only a short hash prefix leaves our servers). Multi-factor authentication enrollment is available in the app.

Sensitive actions are throttled per IP and account: sign-in attempts, password-reset mail, confirmation resend and invite codes each have their own limits.

Data is isolated per workspace using Postgres row-level security. A signed-in user can only read rows for workspaces they belong to, checked by a security-definer function er_is_member(); writes go through the service role. In an independent review, a signed-in user reading nine shared tables saw only their own workspace’s rows and zero foreign rows, and both plan-escalation and role-escalation attempts were refused.

Inbound webhooks (Zernio) are verified with an HMAC-SHA256 signature over the raw request body, compared in constant time, with a freshness window and event-id deduplication so replays are no-ops. The event id and type are taken from the signed body, not from unsigned headers. Stripe webhooks verify Stripe’s own signature. Scheduled jobs authenticate with a header-only shared secret (never a query string, which would leak into logs), compared in constant time.

When EvoViral fetches a link to build a preview, it uses a hardened fetch that resolves the hostname once, rejects private, loopback, link-local, CGNAT and multicast addresses (including IPv4-mapped and transition ranges), pins the connection to the validated public IP, restricts ports to 80/443, and caps the response size. This closes the server-side request forgery and DNS-rebinding holes that a naive fetch would leave open.

Endpoints that spend money upstream or generate files are guarded by an atomic, per-account (or per daily-salted IP) counter in Postgres, which answers 429 when a limit is exceeded. Conversion and export endpoints are limited as well, so a single account cannot turn them into a free firehose. These limits fail open on a database blip rather than taking the endpoints down.

Every response carries a strict content security policy with a per-request nonce and strict-dynamic, plus script-src-attr 'none', object-src 'none', base-uri 'self' and frame-ancestors 'none'. We also send X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, a restrictive Permissions-Policy and Cross-Origin-Opener-Policy: same-origin.

Secrets (database service role, cron key, webhook signing keys, Stripe secret) live only in server-side environment variables and are never shipped to the browser. The service-role client is marked server-only and does not persist sessions. The cron key is stored in a managed vault and injected server-side, so it never appears in a URL.

We keep your data while your account is active. Service event logs (delivery attempts between the platforms and us) are deleted automatically after 30 days. You can export your data and delete your account, with its data, from Settings → Account; disconnecting an account removes its tokens and stops processing for it. See the Privacy Policy §9 for the details.

We do not currently hold SOC 2, ISO 27001 or similar third-party certifications, and we will not claim any we do not have. If your procurement needs one, tell us — we can discuss the current controls, complete a security questionnaire, and share what an independent review has found. Enterprise customers can request our Data Processing Agreement.

We monitor for issues and act on reports. If a security incident affects your data, we will investigate, contain it, and notify affected customers and, where required, regulators. Notification timelines for customers are set out in our DPA.

If you believe you have found a security vulnerability, please report it to us privately via our support desk with enough detail to reproduce it. We ask that you give us a reasonable time to fix it before any public disclosure, and act in good faith — no data destruction, no privacy violations, and no service disruption. We will acknowledge the report and keep you updated.