Security & privacy at Spey Register

Every connection to Spey Register is served exclusively over HTTPS. Each connection opens with a TLS handshake that authenticates our server against its certificate and negotiates fresh, ephemeral keys; from that point on, every request and response is protected with authenticated encryption, so a network observer can neither read nor tamper with the payload undetected. We support TLS 1.2 or higher, and certificates are provisioned and rotated automatically by our hosting and CDN provider — removing the risk of an expired or mis-configured certificate slipping through.

On top of TLS we send an HTTP Strict Transport Security header: max-age=31536000; includeSubDomains; preload. Read literally: max-age tells the browser to treat the origin as HTTPS-only for a full year, includeSubDomains extends that guarantee to every subdomain, and preload makes the domain eligible for the browser-maintained preload list — so a conforming browser refuses plaintext even on the very first visit, before it has ever seen our header. Together these close the trust-on-first-use gap and neutralise SSL-stripping downgrade attacks that depend on an initial, unencrypted http:// request.

Data stored in our managed Postgres database is encrypted at rest by the database provider. If the underlying storage media were ever accessed directly, the contents would remain unreadable without the provider-managed keys.

Row-Level Security (RLS) is enabled on every single table, with a deny-by-default posture: unless a policy explicitly grants access to a given row, that row is invisible. Crucially, these policies are evaluated by PostgreSQL itself — per row and per query — a second, independent enforcement point beneath the application. So even if an application code path were wrong, the database simply will not return rows the current context is not entitled to. That is defence-in-depth applied literally: two independent gates, not one.

Application data is stored in the UK: the managed database runs in the London region (eu-west-2). Data at rest stays within that jurisdiction.

All input is validated against a single shared schema that runs on both the client and the server. The same rules that give you fast, friendly feedback in the browser are re-enforced on the server, where they actually count — so malformed or malicious input cannot bypass validation by skipping the front end.

Each response carries a Content-Security-Policy built around a fresh, per-request nonce: only scripts tagged with that exact, unpredictable value are allowed to run, so injected inline script — the payload of a classic cross-site-scripting attack — has no way to guess the nonce and the browser refuses to execute it. We also send X-Content-Type-Options: nosniff to stop the browser from MIME-sniffing a response into an executable type, alongside the other standard security headers including HSTS.

Uploaded files are held in private storage — never in a public bucket. They are delivered only through short-lived signed URLs that expire, and both file type and size limits are enforced on the server. There is no persistent public link to a document, so access ends when the signed link does.

Sensitive endpoints are rate-limited to blunt automated abuse such as credential-stuffing and brute-force attempts, reducing how quickly an attacker can probe the platform.