Security
This page describes the technical and organizational measures we implement to protect the data we process. The measures are kept under review and may evolve over time.
1. Data Minimization Through Architecture
- Transient image processing. Submitted images are not stored at rest. They are held only in memory and on temporary processing buffers for the duration of analysis, and deleted immediately afterward. This is the central data-minimization measure of the Service.
- Time-limited PDF retention. Generated PDF reports are retained for a fixed period (7, 14, or 30 days depending on product) and then deleted automatically.
- User-initiated deletion. Users can delete a specific analysis on demand, removing the PDF, the preview, and operational metadata.
- No long-term log retention of personal content. Operational logs do not contain personal content. Application logs are kept only as needed for diagnostics and rotated regularly.
2. Encryption
- In transit: TLS 1.2 or higher for all client connections and for connections between our services and subprocessors.
- At rest: object storage uses provider-managed encryption (Cloudflare R2). Application database storage is encrypted at the disk level by the host.
- Passwords: stored as bcrypt hashes only. Plaintext passwords are never stored.
- API keys: stored as SHA-256 hashes only. Plaintext keys are shown once at creation and never again.
- Webhook signatures: webhook payloads are signed with HMAC-SHA256 using a per-key secret, allowing receivers to verify authenticity.
3. Access Controls
- Authentication for users via session cookies (HttpOnly, Secure, SameSite=Lax).
- Authentication for API integrations via API keys with scoped permissions and revocation.
- CSRF protection on all state-changing web requests.
- Role-based access controls separating administrative, agency, model, and API contexts.
- Least-privilege principle for service accounts and infrastructure access.
4. Network and Application Security
- HTTPS-only enforcement with HSTS.
- Security response headers (X-Content-Type-Options, X-Frame-Options, Content-Security-Policy, Referrer-Policy).
- Rate limiting at the request level to mitigate brute-force and abuse.
- Input validation and parameterized database queries to mitigate injection attacks.
- Idempotency safeguards on mutation endpoints to mitigate replay and duplicate-submission abuse.
5. Operational Security
- Backups taken regularly and retained for a limited period; restoration tested periodically.
- Monitoring for service health, error rates, and anomalous activity.
- Heartbeat checks on background workers; alerting on stalls.
- Change management with versioned migrations and audited deployments.
- Periodic review of access privileges, secrets, and dependency versions.
6. Incident Response
We maintain an internal procedure for handling security incidents, including identification, containment, investigation, and notification. Where a Personal Data Breach affects data we process, we will notify affected Customers and, where applicable, regulators and Data Subjects, in accordance with applicable law and the Data Processing Agreement.
7. Subprocessor Security
We engage subprocessors only where they meet our security expectations. Each subprocessor is contractually bound to security obligations materially equivalent to those described here. Our current subprocessor list is published at /legal/subprocessors.
8. Limitations
No system can guarantee absolute security. The measures described here are designed to reduce risk, not eliminate it. Users must take their own steps to protect their accounts: use a strong unique password, keep credentials confidential, and report suspected compromise promptly.
9. Reporting a Vulnerability
If you believe you have discovered a security issue affecting the Service, please report it via the contact channel listed in the Privacy Policy. Please give us a reasonable opportunity to address the issue before public disclosure.