Security overview

Accounts and authentication

• Passwords are stored as scrypt hashes with per-password salts, at interactive-login cost parameters. We never store, log or transmit a password, and cannot recover one.
• Passwords must be at least ten characters, are checked against the passwords that actually get guessed first, and may not contain your own name or email.
• A session cookie is 32 bytes from the operating system's cryptographic random generator. Only its SHA-256 hash is stored, so a copy of our database is not a set of working logins. Comparisons are constant time.
• Session cookies are HTTP-only, SameSite=Lax and TLS-only in production. No script can read one, and a cross-site request cannot carry one.
• Sign-in is throttled after eight failures in fifteen minutes, keyed by both email address and network address — one so an attacker cannot work down a list of accounts, the other so one person's typo does not lock out their whole office.
• A second factor is available on any account: a time-based code from an authenticator app, RFC 6238. The shared secret is encrypted at rest rather than stored plainly — a password is a hash and cannot be reversed, but a code secret is symmetric, so anybody holding it could produce valid codes indefinitely. Whoever runs an organization can require it of everybody. Recovery codes exist so that losing a phone is not losing an account, and only their hashes are kept.
• Changing a password ends every other session on the account, which is the point of changing it if somebody else had the old one. Turning off the second factor costs the password, because that is the first thing somebody with a stolen session would try to do.
• Suspending an account takes effect on the next request rather than when the session would have expired.

Access control and tenant isolation

• Every database query that reads or writes team data is scoped by the team on the server-side session, never by an identifier supplied by the browser. An id in a form field is treated as a request, not a fact.
• Roles are read from a person's membership of a specific team, so the same person can lead one team and be an ordinary member of another without either leaking into the other.
• The screens a leader sees never load the original text of a message or its author reference. This is enforced by the queries rather than by the interface.
• A topic is withheld from a leader until three different people have raised something under it — a count of people, not of messages.

The application surface

• A Content Security Policy restricts scripts, styles, images, fonts and network connections to this origin. There is no external script host, no CDN and no analytics, so there is nowhere for injected code to send anything. unsafe-eval is not present in a production build.
• frame-ancestors: none and X-Frame-Options: DENY — the product cannot be framed, so it cannot be clickjacked.
• form-action: self — a rewritten form target cannot post somebody's message to another origin.
• HTTP Strict Transport Security with a two-year max-age, subdomains and preload.
• Invitation links are looked up by hash, never stored in the clear, and the page that receives one sends no referrer and is never cached.
• Database access is entirely through parameterised queries; the application builds no SQL by concatenation. Rendering escapes every interpolated value and uses no raw HTML injection anywhere.
• Input is length-limited and stripped of control characters at the boundary.

Data

• In transit: TLS, enforced by HSTS.
• At rest, twice over. Neon encrypts storage with AES-256 and holds SOC 2 Type II. Render, which runs the application, holds SOC 2 Type II as well.
• And once more for the part that matters most. The original text of every message, and the record of what the rewriter changed, are encrypted in the column with a key the application holds rather than the database. A stolen backup, a leaked dump or a copy of a replica does not open them. What that does not defeat is somebody who can run our application code, because the key is in its environment — so this narrows the risk rather than removing it, and the privacy notice says so in the same words.
• Payments: Stripe, PCI DSS Level 1. Card details are entered on Stripe's own pages and never reach our servers, so a compromise of this application cannot expose one.
• Backups: Neon holds continuous point-in-time recovery over a rolling window, so any moment in it can be restored. No restore has been performed from these backups yet, which makes them a hope rather than a proven control — the first one happens before Glass Box holds an organization's data in anger.
• Retention periods for each kind of record are in the privacy notice and enforced by a scheduled job rather than by intention.
• Deletion: people can erase their own account and contributions from inside the product, and a workspace is deleted on termination.

Development and operations

• Every change goes through typecheck, unit tests, a route reachability test, an automated accessibility and contrast check, and a full walk-through of the product as each role on a freshly created organization.
• Dependencies are deliberately few, and `npm audit` reports none with a known vulnerability. The production runtime carries no analytics, no telemetry and no third-party client other than Stripe's, which is reached only from the billing pages.
• Secrets are supplied as environment variables and are never committed. Nothing in the repository contains a credential.
• Structured server-side logging of errors on the action and API paths. Logs do not contain message content or passwords.
• Dependencies are audited on every install and in continuous integration; the build fails on a known high-severity advisory in anything that ships to production. There are currently none.

Incident response

If we become aware of a personal data breach we will notify affected customers without undue delay, and within the period committed in the data processing addendum. The notice will describe what happened, what data was affected, the likely consequences, what we have done, and who to contact.

Our procedure, in order:

1. Contain — revoke the credential or path, and end affected sessions.
2. Assess — what data, whose, how much, and for how long it was reachable.
3. Notify affected customers as controllers, with what we know at the time.
4. Remediate, and fix the class of problem rather than the instance.
5. Write it up, including what let it happen and what we changed.

Report something to [email protected]. We will acknowledge within two business days. We do not take legal action against good-faith researchers who give us reasonable time before publishing.

What we have not built yet

Stated plainly so you can decide with the facts in front of you.

• Multi-factor authentication is available but not yet required by default.Any account can turn on a time-based code from an authenticator app, and whoever runs an organization can require it of everybody. What is not built is SSO. If your policy requires SAML or SCIM today, Glass Box does not meet it.
• Email verification does not yet gate access. New addresses are sent a confirmation link and the result is recorded, but an unconfirmed account is not blocked — enforcing a rule introduced after existing customers signed up would lock them out to no benefit. It will gate new signups once the backfill is done.
• No single sign-on. No SAML or SCIM provisioning.
• No customer-visible audit log. Administrative actions are not yet surfaced to you as a reviewable trail.
• No SOC 2 report and no ISO 27001 certificate. These are frameworks rather than laws, and we have not been through either yet. We would rather say nothing than name a date we have not planned for.
• No independent penetration test yet. One will be commissioned before Glass Box is sold to an organization large enough to ask for the report, rather than during that conversation.
• Single instance. Realtime updates are held in the application's memory, so the service runs as one instance without automatic failover. Deploys cause a brief interruption.
• Anonymity has limits. The rewriting removes names, pronouns and identifying details, and a topic needs three different people before a leader sees it — but on a small team, or where a role is unique, an author may still be guessable to a colleague who is trying. The privacy notice sets out exactly what is and is not protected, and it is worth telling your people the same thing.