Summary
Compliance Locker is designed around zero-knowledge principles: document encryption and decryption occur in your browser, and the service operator does not receive your master password in readable form. This page summarizes current technical controls. It is not a warranty, certification, or guarantee of security outcomes.
Client-side cryptography
Vault operations use the browser Web Crypto API. Your master password is combined with a per-user salt and domain separation values to derive keys locally. Plaintext document contents are not intentionally transmitted to our servers during normal upload or download flows.
Cryptographic parameters
- Key derivation: PBKDF2 with SHA-256, 600,000 iterations, and a 256-bit derived key used for vault operations
- Symmetric encryption: AES-GCM with 256-bit keys for file payloads and metadata
- Per-file keys: each document uses a randomly generated file encryption key (FEK), wrapped with your derived vault key before storage
- Collaboration: RSA-OAEP wraps file encryption keys for designated collaborators using their registered public keys
- Share links: decryption key material is placed in the URL fragment (#) so it is not sent to servers in standard HTTP request headers
Authentication
Password verification uses a client-side hash with an additional server-side pepper before database storage. We do not store reusable master passwords.
Authenticated sessions use an HTTP-only, signed cookie named cl_session with SameSite=Strict and a seven (7) day maximum lifetime unless you log out sooner. In production, the cookie is marked Secure.
Authorization and storage access
API routes validate session identity server-side before returning or mutating vault records. Encrypted object downloads require ownership, valid collaboration grants, or an unexpired share token as applicable. Storage object keys are scoped to user identifiers to reduce cross-tenant access risk.
Data in transit and at rest
Browser-to-service communication uses HTTPS/TLS. Encrypted file blobs are stored in Cloudflare R2-compatible object storage. Structured metadata, account records, and audit events are stored in a managed PostgreSQL database. Application hosting and runtime infrastructure may be provided by third-party cloud platforms.
Audit logging
Security-relevant events are written to an insert-only audit ledger. Entries use pseudonymized actor and network identifiers rather than storing raw session tokens in audit rows. See our Compliance overview.
Operational practices
We aim to apply least-privilege access to production systems, segregate environments, rotate credentials, and monitor for abuse. No operational practice eliminates all risk.
To report a security concern, email support@compliancelocker.app with sufficient detail for reproduction. Please do not test against production systems without prior written authorization.
Your responsibilities
- Use a strong, unique master password and protect recovery materials
- Lock your vault when leaving an unlocked session unattended
- Revoke share links and collaborator access when no longer needed
- Maintain endpoint security on devices used to access the Service
- Classify data appropriately before upload and train authorized users
Residual risk
Endpoint compromise, phishing, device theft, weak passwords, clipboard leakage, browser extensions, or disclosure of full share URLs (including fragments) can expose data despite strong encryption. Compliance Locker should be used as part of a broader information security and compliance program, not as a substitute for organizational policies, training, or legal advice.
The information on this page is provided for general informational purposes only and does not constitute legal, regulatory, or professional advice. You are responsible for determining whether the Service meets your compliance obligations.