Security

How sign-ins and tokens are handled

• People sign in on Meta’s and Google’s own pages. We never see a password, a two-factor code or a passkey.
• The access token we get back is encrypted with AES-256-GCM before it is stored. Each stored value is tied to the session and purpose it belongs to, so a value copied onto another record cannot be opened.
• A client’s token lives for at most 30 minutes. The database enforces that limit itself, with one minute of slack. When the session ends we revoke the token at Meta or Google and delete our copy. A background job sweeps for anything left behind every 5 minutes.
• We ask for no key that outlives a client’s session.
• An agency’s own Facebook and Google sign-ins (Connections) are encrypted the same way. They are kept until the same person connects again, the owner disconnects them (we delete them and revoke them at Meta or Google), the person deletes their account, or the agency is deleted. One that stops working (it ran out, or the person removed our access at Meta or Google) is deleted 30 days after it stopped.
• Tokens are never written to logs, job data, the audit log, error messages or analytics.

Links and sessions

• A request link carries 128 random bits. We find it by its SHA-256 hash. The link itself is stored encrypted, only so that the agency can copy it again.
• A browser proves that it owns a client session with a signed cookie that scripts cannot read. We store only a hash of its secret.
• Each round trip to Meta or Google carries a value that can be used once, stored as a hash.
• Link pages send no referrer, are never cached, and are closed to search engines.

What is stored

• Agency users: name and email address, for as long as the account exists.
• For each request: the assets the client chose, the business that owns each one, and what was given or is still pending.
• The person who signed in for a client: name, email address and platform ID, until the session ends. They are never given to the agency.
• Other people with access to a Google account the client chose: read at that moment, to see whether the agency already has access, and never stored.
• A log of who did what, by ID and not by name. The application cannot delete an entry or change what it says was done, whichever role it acts as. It can only forget a deleted agency, client or person, and clear the hashed IP address after 30 days.
• A keyed hash of an IP address where our code needs one to limit misuse. Not the address. On the log of who did what, it is cleared after 30 days.
• One exception, outside our code: the sign-in service for agency accounts keeps the email address and IP address of each sign-in and sign-up in its own log for 90 days, and the IP address and browser of each signed-in session until it ends, at the latest after 30 days without use or 90 days after the sign-in.

What is not stored

• A client’s token after the session.
• Passwords to Meta or Google, two-factor codes, passkeys or identity documents.
• Names or email addresses of individual people in logs, job data, audit entries or error messages.
• Assets the client did not choose, once the session is over.
• Ad results, spend, audiences or creative material.
• Card details.

Keeping agencies apart

• Every record that belongs to an agency carries that agency’s ID, and the database itself enforces that a signed-in user can read only the records of agencies they belong to. An automated test proves that one agency cannot read another’s.
• The browser never talks to the database. Every read and write goes through our server.
• Secrets, encrypted tokens and hashes sit in a part of the database that only the server can reach.
• An agency cannot change its own verification level, limits or status.

Guard rails on changes

• Nothing changes in a client’s accounts without the client’s click.
• The tool only adds access. It does not remove or lower anyone’s access, and it does not raise a lower role someone already has.
• It never writes to an asset that another business owns, whatever role the client has on it.
• A change we could not confirm is shown as waiting until it has been checked.
• A note that an agency writes on a link cannot contain a web address. The database rejects it.

The web application

• A strict Content-Security-Policy with a fresh nonce on every request: no inline scripts, no scripts from third parties, and fonts and images from our own server only.
• No page can be framed by another site.
• No analytics service, no advertising cookies and no third-party trackers.
• Our own server counts views of the public pages: per day, per page and per referring site, by its name only (such as www.google.com). No IP address, cookie, query string or browser details are kept with the count.
• Rate limits are keyed on a hash of the IP address.

Where it runs

• On servers at Hetzner in Finland, in the EU. The application, the database and the sign-in service all run there, operated by us.
• The database is not reachable from the internet. Only the web application is.
• Email: [EMAIL DELIVERY PROVIDER TO BE CHOSEN]. Until one is set up, messages are held and not sent.
• Meta and Google: during a session we call their systems with the signed-in person’s token. They handle that data under their own terms.

Reporting a problem

Write to abuse@adcato.com. Say what you found, how to reproduce it and how we can reach you. The same address is in /.well-known/security.txt, and it also takes reports of request links that look like phishing. A client can also use “Report this request” on the link page.

• Please give us time to fix a problem before you publish it.
• There is no bug bounty.
• If personal data is affected, we notify the Norwegian Data Protection Authority within 72 hours where the law requires it, and tell the agencies affected without undue delay.

What is not in place yet

• No SOC 2 or ISO 27001 report.
• No penetration test by an outside firm. One is planned before agencies use the product with real clients.
• Meta and Google have not reviewed or approved the app. Until they do, it works with simulated accounts and test accounts only.
• The key that encrypts stored tokens is held in the server’s environment, not in a key management service or a hardware module.
• No automated off-site backup, and no tested restore.
• The legal documents on this site, the data processing agreement and the list of sub-processors among them, are drafts that a lawyer has not reviewed.
• No public status page, and no uptime commitment.