Security

Every private read and every write resolves the account and the website on the server. The account comes from the session of the signed in user, and the website is proved to belong to that account before a single row is read. A website id, an account id, a role, a plan or a price sent by a client is never trusted.

Identifiers are opaque random strings, and a sequential database id is never used as an authorisation token. Background jobs carry the tenant and site scope in the message and the consumer checks it again before it writes.

Visitor identifiers are derived on the server with a keyed hash over the website identifier, a per website salt and a server side pepper. The raw value from the browser is never stored, and the same browser produces a different identifier on a different website. Rotating the salt of a website resets its visitor identity.

No event contains an IP address. The country is a coarse two letter code, and the device, browser and operating system labels are families rather than fingerprints.

Every payload is validated on the server with a schema library before it is read, normalised or stored. Payloads are size limited, string lengths are capped, the number of properties is capped, nested structures are limited in depth, and property keys that look sensitive are dropped.

Event names are restricted to a safe character set. Reserved words cannot be used as event names, so a customer event can never be mistaken for a billing event.

All queries use parameterised statements with bound values. No request value is concatenated into SQL, including the dimensions, ranges and sort keys that come from a query string. The dimension and range allowlists are checked before a query is built.

Public ingestion is rate limited at the edge, per website and per client address. A request over the limit is refused with a retry hint instead of being processed. Server-to-server requests are metered against the monthly event quota of the account, and a body over the size limit is rejected before it is parsed.

Webhooks are verified against the raw request body before the payload is trusted. The signature is compared in constant time, and a request whose timestamp falls outside the replay window is rejected. Provider event identifiers are stored so a repeated delivery is processed once.

An API key is a prefix and a secret. The secret is generated with a cryptographically secure generator, shown exactly once when the key is created, and stored only as a keyed digest. The raw secret cannot be recovered later, so a lost key has to be replaced. Keys can be revoked and expire, and each key carries explicit scopes and is bound to a single website.

A session token is a high entropy random value. Only its digest is stored, so a database leak does not expose a usable credential. The session cookie is marked httpOnly and SameSite, and it is marked Secure outside development.

Passwords are stored as a salted PBKDF2 hash and are compared in constant time. A failed sign in still performs the password check, so a missing account and a wrong password take a similar amount of time.

State changing requests check the origin of the request and are refused when it does not match the application. Ingestion checks the request origin against the allowlisted domains of the website. Origin is treated as one signal among several and never as the only control, because a non browser client can send any header it likes.

Raw events are removed when the retention window of the plan ends, and the derived aggregates for those days are removed with them. Deleting a website removes its events, sessions, aggregates, goals, funnels, API keys, integrations and revenue records. Removal jobs are scoped to one website and are safe to run again.

This page does not claim an audit, a certification, a penetration test or an uptime target, because none of those are in place yet. We do not claim that the service is compliant with any specific regulation, and we do not publish a performance benchmark that we have not measured. If a claim matters to you, ask us for the evidence behind it.

If you find a security problem, report it to security@aback.com with the steps to reproduce it and the impact you believe it has. The address is a placeholder in this build and should be replaced with a monitored mailbox before launch.

Please do not test against other customers, do not exfiltrate data, and do not degrade the service for other people while you look for the problem.

The privacy documentation describes what the tracking script collects and what the server stores. The API reference describes the authentication header, the response envelope and the error codes.