Security

How the system is built to protect what it holds — and where it is still weak.

Draft — not yet reviewed by a lawyer This document was drafted from the Snapfiled source code so that it describes what the software genuinely does. It has not been reviewed by a qualified lawyer, it is not legal advice, and it must be reviewed and adopted before Snapfiled takes money from anyone or signs a customer agreement. Facts in it are accurate as of the code it was written against; the legal framing around those facts is not warranted.

Last updated 23 August 2026 · Operated by [COMPANY_LEGAL_NAME — not configured] · Questions: [email protected]

What we are protecting

Three things, in descending order of how much damage their loss would do: CRM credentials (a stolen token is a customer's entire pipeline), capture images (third-party personal data that the people in them never handed to us), and extracted records (the same data, structured).

Encryption

In transit. HTTPS to the app, TLS to the model providers, to your CRM, and to the SMS and email providers.
CRM credentials at rest. Every field an adapter marks secret is encrypted with AES-256-GCM under a server-side key before it is written to the database, and decrypted only in memory at the moment of a push. The settings page never shows a credential back in full — only a mask and the last four characters, enough to recognise which key you pasted.
API keys and sessions. API keys are stored as a SHA-256 hash with a short display prefix; the full key exists once, in the response that created it. Sign-in links are single-use and expire in twenty minutes.

Separation between customers

Every table is scoped by organisation and every query is filtered by it. Stored photographs are not served by URL alone: a storage key is not a capability, so each file read is authorised against the capture it belongs to and a key from another organisation returns a 404. Captures are only accepted from addresses and numbers on your allow-list, so a wrong number cannot post into your account.

The browser

A Content-Security-Policy with a per-request nonce, no third-party scripts, no analytics. Session cookies are HttpOnly, SameSite=Lax and signed. Every state-changing form carries a CSRF token derived from the session. HSTS in production.

If someone stole the database

They would get capture text, extracted records, email addresses, phone numbers and the audit trail — a serious breach, and we would notify you. They would not get usable CRM credentials, API keys or session tokens without also stealing the server's encryption key, because those are encrypted or hashed. If they took the whole server, they would have the key too. We do not pretend otherwise.

Where we are weak — honestly

One server. Single VPS. No multi-region failover; a host failure is an outage.
One encryption key. Credentials are encrypted under a single server key, not per-tenant keys. Compromise of that key exposes every tenant's credentials.
No SOC 2, no ISO 27001, no penetration test report. If you need one to buy, we do not have one yet.
Backups. Encrypted only if the operator configured that. Ask before assuming.
Model providers. Image contents leave our infrastructure by design. See the Privacy Policy.

The full engineering write-up, including the trust boundaries and the inbound authentication story, is in docs/SECURITY.md in the source. Ask and we will send it.

Reporting a vulnerability

Email [email protected] with "security" in the subject. We will acknowledge within two business days. Good-faith research that does not access other customers' data, degrade the service or exfiltrate anything will not be met with legal action.