Security
Adrevox holds no security certification, and this page does not imply one.
What it does instead is name the things that would have to fail for one client to see another client’s data — and say what catches each one.
The shape of it
One check is a policy. Three independent checks, where the last one does not trust the software at all, is an architecture.
01
Who may call it
Every request is checked against the role making it, before anything runs.
02
Which rows they may touch
A valid role with the wrong customer’s identifier is refused at the boundary.
03
The database itself
Even if both checks above are bypassed by a bug, the database returns nothing.
The specifics
It connects to the database as a restricted account that has no power to ignore row-level rules — and refuses to start at all if it is ever given one.
Enforced by
A boot-time check. Misconfigure it and the service does not come up.
Every table holding customer data enforces its rules against every caller, including the table’s own owner — the case where isolation usually turns out to be decorative.
Enforced by
A guard that scans every table on every commit and fails the build.
The customer identity a query runs under is scoped to that single transaction, so a reused database connection cannot carry it to whoever borrows it next.
Enforced by
The mechanism itself — the value is discarded when the transaction ends.
A test tries to read one customer’s rows while acting as another, on every commit. If a single row comes back, nothing ships.
Enforced by
Continuous integration. It has to pass before any deploy runs.
Payment details are entered in the payment provider’s own checkout. They do not pass through Adrevox servers and are not stored here in any form.
Enforced by
There is no field for them anywhere in this codebase.
A notification’s signature is checked against the untouched original message before anything in it is interpreted — the order that prevents a forged message being processed.
Enforced by
An invalid signature is recorded and rejected, never acted on.
Session cookies are HTTPS-only, unreadable by page scripts, and are not sent when another site links to us.
Enforced by
Cookie flags set by the server, checked by the production verification run.
Authorisation headers, cookies, passwords, tokens, signatures, phone numbers and email addresses are stripped before anything is recorded.
Enforced by
A redaction list applied at the logger, not at each call site.
Every build checks the whole dependency tree against the public advisory database and fails on a high-severity finding.
Enforced by
Continuous integration, on every commit — not a quarterly review.
The database and the application both run in India, and the record of your enquiries belongs to your account rather than to an advertising platform.
Enforced by
Where the infrastructure is provisioned.
Not done yet
Every security page lists strengths. This is the part that is worth reading.
The internal admin and staff surfaces it applies to are not in production. It lands before either of them ships.
There is no file upload anywhere on the site or in the portal today. Scanning arrives with the first one, not after it.
Send them over. We would rather answer a hard one now than have it surface after you have signed something.
