BeforeRed only reads the public, official, documented APIs your providers already publish. We never see your source code, your database rows, your customer data, or your environment. This page explains exactly what we do, what we don't, and where we are right now.
These are not slogans. They are the rules that decide what BeforeRed ships and what BeforeRed refuses to ship. They are derived from the product constitution, PRD §48 to §51, and §79. Every feature has to fit inside them.
Minimum scopes, where the provider supports it.
We prefer OAuth over personal access tokens. When a provider exposes a read-only scope (Supabase, Vercel, Render, and most others we ship first), we ask for that scope and nothing else. We never ask for service-role keys, database passwords, .env files, GitHub repository secrets, or any cloud admin key that would let us touch your infrastructure. PRD §48.3.
Per-credential key, server-only master key.
Every provider token is encrypted at rest with application-level envelope encryption: a random data-encryption key (DEK) per credential, wrapped by a server-only key-encryption key (KEK) that lives in production secret infrastructure. The DEK is never written to disk in plaintext. Tokens are never sent back to the browser after the OAuth exchange. PRD §48.
We read usage, not your data.
BeforeRed never reads your application source code. Never reads database rows. Never reads customer emails. Never reads your environment variables. Never reads your user passwords. The product is built around a single line: we monitor your usage, not your users. PRD §79.
Only official, documented provider APIs.
We do not reverse-engineer provider dashboards. We do not depend on undocumented internal endpoints. We do not pull HTML or scrape web pages. Every value BeforeRed shows you comes from a documented public API that the provider publishes and supports. If a value is not exposed by that API, we show unknown. PRD §9.4, constitution rule 4.
Revoke token, shred credential, stop sync.
Every connection has a one-click disconnect. On disconnect, we revoke the token with the provider when supported, shred the encrypted credential, stop all sync jobs for that connection, and mark the connection as disconnected. You are then offered Delete history too, which removes every snapshot we stored from that connection. PRD §51.
IDOR tests on every route that touches a project.
Every app, project, and connection query requires ownership verification on the server. We never trust a user ID, workspace ID, or connection ID that comes from the client. Row-level security (where the database supports it) is a second layer, not a substitute. IDOR tests are mandatory in our test suite. PRD §50.
BeforeRed's job is to read usage, plan, and aggregate limits. The provider APIs we depend on are designed to expose these values without exposing user data. When a value requires sensitive data to compute, we prefer to show unknown rather than ask for credentials that would let us see more than we should.
If a provider adds a new metric to its API, we can only ship it once it is documented and supported. We will not depend on undocumented endpoints even if they exist.
If you connect a provider and do not see a metric you expect, it is almost always one of: not exposed by the API, behind a scope we do not request, or not yet certified on our side.
Every provider token is encrypted before it touches our database. The encryption uses envelope encryption with a per-credential key. The master key never leaves the secret store. Tokens are never returned to the browser after the OAuth exchange, and they are never written to logs in any form.
Every token is stored as ciphertext plus a wrapped key reference. AES-256-GCM. The encryption happens inside a server-side module that only ever sees plaintext tokens for the few hundred milliseconds needed to encrypt them.
The KEK lives in production secret infrastructure. Application code reads ciphertext and wrapped keys from the database. The KEK is loaded only inside the encryption module. Operators cannot pull plaintext tokens from the admin UI.
The envelope pattern means we can rotate the KEK without re-encrypting every token from scratch. We re-wrap DEKs under a new KEK during a normal rotation window. We can also rotate a single DEK at any time without touching the KEK.
Tokens never appear in request logs, error logs, telemetry, or analytics events. Logs are scanned for token-like patterns in CI. Anything that would log a token fails the build.
Server-side request forgery is the kind of bug that turns a monitoring tool into an open proxy. BeforeRed is designed so that there is no way to use it as one. Every adapter has a narrow, static route to one or two provider domains and nothing else.
Every outbound request from a provider adapter targets a hardcoded domain on a static allowlist. The Supabase adapter only calls api.supabase.com and *.supabase.co. The Vercel adapter only calls api.vercel.com. There is no config field, no user setting, and no request body that can change the destination.
ALLOWLIST = [api.supabase.com, *.supabase.co, api.vercel.com, ...]The server never accepts a URL from the client and uses it as a destination for a server-side fetch. We do not pass an apiUrl, webhookUrl, or callbackUrl from the browser into the adapter layer. If a provider lets a user point it at a custom origin, we do not support that surface yet.
HTTPS only. TLS verification on by default. Redirects are followed only within the same allowlisted origin. We require application/json responses. The response body is bounded to a fixed size cap per adapter, so a malicious provider response cannot be used to exhaust memory or storage.
Each adapter has a per-request timeout, a retry policy with exponential backoff, and a per-provider rate limit. Errors are mapped to a structured adapter error type before they ever reach the snapshot layer. The sync job, not the adapter, decides what happens next.
The intent is simple. A BeforeRed sync job should be able to call only the providers its user has connected, only with the scopes they approved, and only to the official documented endpoints. Any other behavior is a bug.
Disconnect is the worst-case test for any security model. If you cannot tell us to stop and have us actually stop, nothing else on this page matters. Here is the exact sequence, in order, that runs the moment you click Disconnect.
When the provider supports token revocation (most OAuth providers do), we call the revocation endpoint on the provider side. The provider then refuses any further use of that token, even if our copy was somehow still valid.
We overwrite the ciphertext and wrapped key reference for the connection in our database. The DEK that was used to encrypt that specific credential is discarded. There is nothing left on our side to decrypt, even if our database were dumped later.
Active and scheduled sync jobs for that connection are canceled. The sync engine refuses to retry a job whose connection has been disconnected. No new usage data is read for that provider until you reconnect.
The connection status moves to disconnected in your dashboard. The connection can be reconnected later with a fresh OAuth flow. Nothing about your app or your other connections changes because of this one.
We surface a one-click Delete history too on the disconnected connection. If you confirm, every snapshot we wrote for that connection is removed. The connection record is kept so you can see what was there; the historical data is gone.
Delete account removes your apps, every credential we held, every snapshot, every alert, every notification preference, and your personal metadata. Active subscriptions are canceled per the billing policy. Provider mappings are removed. Any anonymized aggregate we keep is documented in the privacy policy and is the only thing that survives.
We would rather be honest about the size of our security program than borrow credibility from a certificate we do not hold. The list below is the actual state of the product and the company, not the marketing version.
If a security claim is not on this page, we are not making it. When we ship something here, this page is the place to verify it. When we move an item from in flight to in place, we update the page first and announce the change after.
Real questions builders have asked. If yours is not here, email us at security@beforered.com. We will answer and add it to the list.
No. We do not request access to your source control, your git history, your build logs, or your code repositories. Hosting providers expose bandwidth, build minutes, and invocation counts through their public API. That is all we read. The read-only OAuth scopes we request cannot read source code even if you wanted us to.
No. The provider APIs we depend on are designed to expose usage, not data. A Supabase token with read-only scopes cannot read row contents. A Resend token with the reporting scope cannot read recipient addresses. We have no API path that lets us see customer emails, user records, or any row in your database. If a metric ever required that, we would refuse to ship it.
An attacker gets encrypted ciphertext and wrapped keys, not plaintext tokens. The KEK lives in production secret infrastructure and is not stored in the application database. Tokens cannot be used without unwrapping their DEK, which requires the KEK, which is not in the same system. We would rotate the KEK and re-wrap every DEK in a single window, then revoke every active token at the provider as a second precaution. We would also publish a postmortem and email every affected user.
Yes. From Settings, you can export every snapshot, every connection, and every alert we have on file for you, in a portable JSON format. The export is generated server-side and is yours to keep. If you want to leave, the export is the first step; the second step is account deletion.
Not yet. We are planning a public bug bounty for the first window after V1 ships. Until then, the fastest way to reach us about a security issue is security@beforered.com. We respond to valid reports, we will not pursue legal action against good-faith research, and we will credit you in the postmortem if you want us to.
Encrypted at rest in our application database. Each token is wrapped with a per-credential DEK. The DEK is wrapped with a server-only KEK. The KEK is not in the database. The application code that decrypts a token runs only on the server. Tokens are never sent back to the browser after the OAuth exchange, and they never appear in our logs.
Not yet. We are pursuing SOC 2 Type II and the target is the audit window after the V1 public launch. We will not call ourselves SOC 2 compliant before the report is in hand. The Where we are right now section of this page is the source of truth and it is updated before any announcement.
Settings, then Security, then Delete account. We confirm by email. Once you confirm, we delete your apps, your credentials, your snapshots, your alerts, your notification preferences, your personal metadata, and your provider mappings. Active subscriptions are canceled per the billing policy. Anonymized aggregates that survive deletion are listed in the privacy policy.
Email us first. We will respond within two business days. We will not pursue legal action against good-faith research. We will credit you in the postmortem if you want us to.
security@beforered.comPGP key available on request. For sensitive reports, ask for the key and we will send it before the report lands in plaintext.
The full security model lives in the product constitution and in PRD §48 to §51. The privacy policy covers retention, residency, and what we never collect. The docs walk through each provider connection step by step.
We monitor your usage,
not your users.