Security
DeepRed Connect and Creator Studio have not launched. This page lists the security controls we are building them with and says how far each one has got. We will update it as controls go into production. DeepRed Connect is run by DeepRed LLC, Albuquerque, New Mexico.
| Label | Meaning |
|---|---|
| Planned | Part of our specification. Not built yet |
| In code | Built and tested in our code. Not running in production yet |
| In CI | An automated check that runs on every code change |
1. Connecting accounts
| Control | Status |
|---|---|
| Accounts connect only through each platform's own sign-in and permission screen. We never ask for, see, store or type a creator's platform password, and we never automate a platform login | Planned |
The state value in every sign-in is signed, single-use, tied to the Connect session, and tied to your browser by an HttpOnly, SameSite=Lax cookie | Planned |
| PKCE wherever the platform supports it. We check the issuer (RFC 9207) and the OpenID Connect nonce where the platform supports them | Planned |
| For Meta, "Require App Secret" is on and every call carries an app-secret proof | Planned |
| We read the permissions a creator actually granted and use only those. Each feature asks for the minimum permissions it needs | Planned |
| Mobile apps sign in through the system browser, never an embedded web view | Planned |
| Customers' redirect URLs must be on an allowlist | Planned |
2. Protecting tokens
| Control | Status |
|---|---|
| Envelope encryption. Each token set, connection, customer app secret and customer gets its own random data key. A master key in Google Cloud Key Management Service (a hardware security module key, rotated every 90 days) wraps each data key, bound to what it protects, so a wrapped key won't open if copied elsewhere | Envelope encryption in code, with a local test key provider. Google Cloud KMS provider planned |
| Wrapped data keys are kept only in a key store with no versioning and no backups, with one replica in a second region. Deleting a key there makes every copy of what it sealed unreadable, including copies in backups | Planned |
| Only the service that calls the platforms can decrypt. The sign-in service can only encrypt fresh keys, and our public API can do neither. Tokens are decrypted only in the sign-in callback (which holds the token the platform just sent) and in the worker and proxy processes that call platforms | Planned |
| Every decryption is written to an audit log | Planned |
| Tokens and secrets are redacted from everything the platform HTTP client logs and from recorded test fixtures | In code |
| Tokens never appear in logs anywhere in the service, enforced in the logger itself. Request tracing and invocation logs are switched off, because they would record headers and query strings | Planned |
| A lock per token set, so a rotating refresh token is never used twice by two workers at once | In code |
Tokens are refreshed before they expire. We detect revocation from platform callbacks, invalid_grant errors and health checks | Planned |
| Customers' own platform app secrets (planned feature) are stored under that customer's key, are write-only and can be rotated | Planned |
3. Keeping customers' data apart
| Control | Status |
|---|---|
| One customer's data is never visible to, or combined with, another customer's, even when the same creator connects to both | Planned |
The application connects to the database with a role that isn't the table owner and can't bypass row-level security. FORCE ROW LEVEL SECURITY is on, the customer context is set per transaction, and every query also binds the customer ID as a parameter | Row-level security in code, with tests. Parameter binding planned |
| Every storage key, cache key, queue message, workflow ID and Durable Object name starts with the customer's ID | Planned |
| Automated tests try to read across customers on every change | In code for the database layer. Other stores planned |
4. Deleting data
| Control | Status |
|---|---|
| On disconnect or revocation, syncing stops at once, and the connection's tokens and data are deleted from every live store within 24 hours | Planned |
| The connection's data keys are deleted within minutes and the deletion is verified, so leftover copies of its tokens can't be read | Planned |
| Deleted rows leave database point-in-time backups within 7 days, and our encrypted disaster-recovery copies within 8 days. A restore replays the log of deletions before any traffic returns | Planned |
| Every deletion is audit-logged, and an alert fires if a deletion is near its deadline | Planned |
Details: connect.deepred.app/data-deletion.
5. Infrastructure and network
| Control | Status |
|---|---|
| The service runs on Cloudflare (Workers, Workflows, Queues, Durable Objects, Containers, R2). The database is PostgreSQL at PlanetScale, on Amazon Web Services in us-east-1, reached only through Cloudflare Hyperdrive with query caching off. The master key is in Google Cloud KMS. Providers and locations: connect.deepred.app/subprocessors | Planned |
| Separate development, staging and production environments, credentials and names. Production data is never copied to development | Planned |
| Deployments only through CI with required reviewers. Only the company owner and the CI tokens can change the production services that decrypt tokens, and a scheduled check alerts on any unexpected change to them | Planned |
| TLS on every endpoint, HSTS, a Content Security Policy and secure cookies | Planned |
| No third-party scripts on Connect pages (connect.deepred.app) | Planned |
| A web application firewall in front of public endpoints | Planned |
| Guards against server-side request forgery on media-by-URL, the API proxy and customer webhook URLs: only http(s), the address is resolved and pinned, private, link-local and cloud-metadata addresses are blocked on IPv4 and IPv6, and redirects aren't followed | Planned |
6. Webhooks and API keys
| Control | Status |
|---|---|
| Every inbound platform webhook is signature-checked with the secret for the app credential named in its URL | Planned |
| Every webhook we send is signed with HMAC-SHA256 over a timestamp and the body, and verified in constant time | In code |
API keys are stored hashed, shown once, scoped (read, publish, admin) and rotatable. The key prefix is registered with GitHub secret scanning | Planned |
7. People and access
| Control | Status |
|---|---|
| Staff and console access requires multi-factor authentication and role-based permissions | Planned |
| Least-privilege cloud permissions. Emergency "break-glass" access is logged | Planned |
| Staff view creator data only with the creator's agreement, for security, or when the law requires it. Every view is logged with the reason | Planned |
| Secrets live only in a secrets manager, never in code, tickets, chat, logs or recordings. A leaked secret is rotated immediately and the incident is logged | Planned |
8. How we build and check the software
| Control | Status |
|---|---|
| Every change goes through a pull request with passing checks and a second reviewer. Changes to the vault, sign-in, tenancy, webhook signatures or deletion also need a security review | Planned |
| Secret scanning of the full git history on every change (gitleaks) | In CI |
| Dependency audit that fails on high and critical advisories | In CI |
| Type checks, lint and tests on every change | In CI |
| Static analysis | Planned |
| A written threat model before the Connect flow ships, covering sign-in forgery and replay, open redirects, token theft, webhook spoofing, request forgery, cross-customer access and abusive customers | Planned |
| Target: OWASP Application Security Verification Standard (ASVS) Level 2 | Planned |
| Independent penetration test before the public API is generally available | Planned |
| SOC 2 Type I readiness work. We hold no SOC 2 report | Planned |
9. Reporting a vulnerability
If you think you've found a security problem in DeepRed Connect, please tell us at security@deepred.app. Our machine-readable contact file is at https://connect.deepred.app/.well-known/security.txt.
Please include:
- what you found and where: the URL, endpoint or app
- steps to reproduce it
- the impact you think it has
- how to reach you
In scope: connect.deepred.app, plus connect-api.deepred.app and studio.deepred.app once they open at launch. Later: connect-docs., connect-console. and connect-status.deepred.app once they open. The DeepRed marketplace at deepred.app is a separate product and not covered here.
Please don't:
- access, change or delete data that isn't yours. Use accounts you own
- test Instagram, Facebook, Threads, YouTube, TikTok, X, LinkedIn, Pinterest, Twitch, Snapchat, Bluesky or any other platform through us. Report their bugs to them
- run denial-of-service tests, spam, social engineering or physical attacks
- publish details before we've fixed the problem or agreed a date with you
What we'll do:
- confirm we received your report within 3 business days
- tell you what we found and our plan within 10 business days
- keep you updated until it's fixed, and credit you if you'd like
We don't run a bug bounty.