Security
Protecting the documents and data our customers entrust to us is the core of what SLDocs does.
How your data is protected
- Encryption at rest. Every document is encrypted with a unique AES-256-GCM key, which is itself wrapped by a per-tenant key held in Google Cloud KMS (envelope encryption). We never store document contents unencrypted.
- Encryption in transit. All traffic is served over HTTPS with HSTS enforced.
- Least-privilege access. Access is role-based and tenant-scoped. Sensitive operations — document downloads, vault access, recovery, support sessions — are recorded in an append-only audit log.
- Continuous monitoring. Automated checks watch for anomalous activity (credential-attack patterns, bulk access, privilege changes) and alert our team.
- Keyless cloud access. Production secrets live in a managed secret store and are reached with short-lived, workload-federated credentials — there is no long-lived cloud key to leak.
Reporting a vulnerability
If you believe you have found a security vulnerability in SLDocs, we want to hear from you. Please email security@sldocs.com with enough detail to reproduce the issue — affected URL or endpoint, steps, and impact. We aim to acknowledge reports within 3 business days.
Please don't email sensitive personal or health information or documents — email isn't encrypted and may be stored outside the U.S. Use your in-product vault instead.
Please give us a reasonable opportunity to investigate and remediate before disclosing publicly. We practice coordinated disclosure and will keep you updated on our progress.
Good-faith safe harbor
We will not pursue or support legal action against researchers who, in good faith, follow this policy: access only their own test data, avoid privacy violations and service degradation, and do not exfiltrate or destroy data. If in doubt, ask us first at the address above.
Please do not
- Access, modify, or delete data that is not your own.
- Run automated scanning that degrades the service, or perform denial-of-service, spam, or social-engineering attacks against our staff or customers.
- Publicly disclose an issue before we have resolved it.
Out of scope
- Reports from automated tools without a demonstrated, exploitable impact (e.g. missing best-practice headers alone).
- Findings in third-party services we integrate with — report those to the vendor.
- Social engineering, physical attacks, and account/email enumeration via timing.
Machine-readable contact details are published at /.well-known/security.txt (RFC 9116).