Security & Encryption

Envelope encryption

Every secret value is encrypted with AES-256-GCM— an authenticated cipher, so tampering with ciphertext is detectable, not just confidentiality. Each organization has its own 256-bit Data Encryption Key (DEK), generated once and wrapped (encrypted) by a single server-held master key. Secret values are encrypted with the org's DEK, never directly with the master key — the master key's only job is wrapping and unwrapping DEKs. This means rotating the master key never requires re-encrypting every secret in the database, only re-wrapping DEKs.

This is server-side encryption, not zero-knowledge — the server can decrypt secrets to serve them to authorized users after an RBAC check. A DEK is never cached unwrapped in memory between requests; it's unwrapped fresh each time it's needed.

Authentication & identity

EnvSync doesn't implement its own password storage or email verification — signing in with Google is the only account-creation path. Google verifies that you actually control the email address before EnvSync ever sees it, which is a stronger guarantee than a self-issued "click this link" verification email could give. There's no password to leak, hash, reset, or brute-force, because there's no password at all.

If an email address already has an EnvSync account (created before this change, or some other way), signing in with Google for that same address links to the existing account rather than creating a duplicate or rejecting the sign-in — the account keeps all of its organizations and data, just with password sign-in retired.

Sessions

Authentication uses short-lived JWT access tokens (HS256, algorithm pinned explicitly) plus a separate, opaque refresh token stored as an httpOnly cookie. Only the refresh token's SHA-256 hash is ever stored server-side — the raw value never touches the database. Refresh tokens rotate on every use: using one revokes it and issues a new one, bounding the damage from a leaked token.

Access control

Every request — whether authenticated by a browser session or a CLI service token — passes through the same role-based access control path. See Roles & Permissions for the full model. Service tokens are hard-scoped to the org they were issued in: a token minted for one organization is rejected outright against any other organization, even if its creator belongs to both.

A service token is also identity-inheriting, not independently scoped: it can only ever do what its creator can do, checked fresh on every call. If a member doesn't have access to a given project — because they were never granted it, or because they only have org-wide visibility without project access — a CLI command against that project's environments is rejected the same way it would be in the browser, not just hidden from a menu.

Rate limiting & headers

Login and signup are rate-limited per IP+email to blunt brute-force and credential-stuffing attempts without locking out a whole shared office IP. A generous global rate limit covers the rest of the API. Every response carries a standard set of security headers (via Helmet on the API, and equivalent headers on the web app) — strict content-type sniffing protection, clickjacking protection, and a Content-Security-Policy in production.

Audit logging

Every mutating action — and every secret reveal — writes an audit log row: who, what, when, and from where. Revealing a secret is always freshly audited, even if you revealed the same value moments earlier; nothing about a reveal is cached client-side to avoid a stale plaintext value sitting in memory unaudited. This applies identically whether the action came from the browser or the CLI — both go through the same service functions, so a pull or push leaves the same trail a manual reveal or edit would.

Logs are append-only in normal use. The Owner can permanently delete entries older than a chosen date from Settings → Organization, for orgs that need to manage log retention — that action is itself logged.

Profile photos

A profile photo is validated server-side before it's stored — its actual bytes are checked against the image format it claims to be, not just trusted from the upload's declared type, and it's size-capped well under the API's request-body limit.

Real-time session control

Revoking a session from Settings takes effect immediately, not on the affected device's next reload. A live event channel notifies connected sessions the moment one of them is revoked.