Security

Security at Glime

Last reviewed September 2026 · Security contact: support@glimecrm.com · Trust center

Glime holds your revenue data — pipeline, pricing, contracts. This page states plainly what we do to protect it, what's independently verified, and what's still on the roadmap. Where we aren't done yet, we say so.

Data protection

• Encryption in transit: TLS 1.2+ everywhere. HSTS is set where TLS terminates — at the edge, as part of the documented deployment, not inside the application container (which would lock a plain-HTTP dev host out of itself).
• Where your data lives: one AWS Lightsail server in us-east-1 runs the API and its Postgres database side by side, behind AWS CloudFront. It is not a managed or replicated database today, and we say so because it decides how much an outage or a lost disk can cost you. The credentials and secrets Glime holds on your behalf — accounting-system tokens, two-factor secrets, chat webhooks — are additionally sealed with AES-256-GCM before they reach the database.
• Tenant isolation, twice: every query is scoped by tenant in the application, and Postgres row-level security walls every signed-in request to its own workspace underneath it — the request runs as a database role that owns nothing and cannot bypass the policy, so a query that forgot its tenant filter still sees one workspace. The few paths that must look across workspaces (sign-in, the public quote link) go through one named door that CI counts. Cross-tenant reads are asserted denied by the test suite on every change.
• Backups: a nightly database dump, kept 14 days, and a daily snapshot of the whole server, stored by AWS apart from it and kept 7 days. Restores are rehearsed with a script that restores a dump into a scratch database and compares every table's row count. There is no point-in-time recovery yet, so in the worst case up to a day of changes could be lost — moving to a managed database with point-in-time recovery is the next infrastructure step, and this line changes when it ships.

Access control

• RBAC with six roles and record-level visibility — a rep sees the accounts they own and their team's pipeline stays out of view. Every route is checked against the same capability table the UI reads, and the server decides: a hidden button is a courtesy, not the control. (Record visibility inside a workspace is enforced in the application; the database's row-level security is the wall between workspaces.)
• Field-level security is partial, and we'll say exactly where. Values in fields your admin adds are enforced by the server: a role that may not read one gets it withheld or masked on every read and in the export, and a change it may not make is refused. Rules over the built-in fields are presentation-only today — hiding one removes it from the screen, not from the API payload — so treat those as tidiness rather than a boundary until server-side column projection covers them too.
• Two-factor sign-in with any authenticator app (TOTP, RFC 6238), on every plan including Free. The secret is encrypted at rest, a code is refused if it has already been used, and ten single-use recovery codes are shown once and stored hashed. An Admin can require it for the whole workspace — a member who hasn't set it up can reach enrollment and nothing else — and can require a fresh second factor (proven in the last 15 minutes) before anyone decides an approval step at or above a chosen rung. A lost phone is a recovery code, or an Admin reset that needs the Admin's own password, signs the person out everywhere, and emails them.
• Sign in with Google or Microsoft (OpenID Connect) on every plan: the ID token's signature, audience, expiry and nonce are all checked, and an account with an authenticator still owes its code afterwards. A workspace that proves it owns its email domain with a DNS record can let colleagues on that domain join without an invite. SAML is on the roadmap, not shipped.
• Session policy: 12-hour expiry, revocable sessions, and a device list — every signed-in session is listed with when and how it signed in, and each can be signed out on its own. Changing your password ends every other session, and an Admin can sign a departing teammate out of every device immediately.
• Password policy: minimum 12 characters, screened against a bundled breach list and against your own name, email, and company, on signup, invite, and change alike. Hashing is bcrypt (cost 10); Argon2id is a roadmap item.
• Brute-force protection: repeated wrong passwords lock the account for a cooling-off period, and a separate ceiling catches one address spraying a common password across many accounts.

Auditability

Every mutation — record changes, quote versions, discounts, approvals, imports, exports, sign-ins and failed sign-ins, role changes — is written to an audit log with actor, timestamp, and detail, through one writer. It is append-only in the database, not just by convention: Postgres refuses an UPDATE, DELETE or TRUNCATE on it. It is also a hash chain: each line carries the hash of the line before, so altering or removing any line breaks every link after it. Your export carries the whole chain, and the verifier (or scripts/verify-audit.mjs) recomputes it on your own machine, uploading nothing. We send the chain's head in the monthly governance email, so history rewritten after you received it would disagree with a hash you already hold — tamper-evident, not tamper-proof, and we say exactly that. Erasing the workspace's data deliberately keeps the log, because an erasure that destroyed its own evidence would leave nobody able to answer who deleted what. Every approved quote carries a certificate over exactly what was approved. See the audit trail live in the sandbox.

Application security

• Strict Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, and Referrer-Policy headers on every response.
• Output encoding on all user data; the API is the only write path — no direct database access exists for extensions.
• Dependency scanning and Lighthouse/security budgets in CI on every change.

Compliance roadmap — the honest version

Data residency

All hosting is in the United States (AWS us-east-1). EU data residency is not offered today. Current subprocessors and regions are listed here.

Reporting a vulnerability

Email support@glimecrm.com, also published at /.well-known/security.txt. We acknowledge within 24 hours, and good-faith research that respects user privacy, avoids service disruption, and allows a reasonable remediation window will not be met with legal action. We credit fixes in the changelog if you'd like the mention. Please don't file a vulnerability as a public issue.