Security

The Service holds two particularly sensitive things: the credentials that allow your ad accounts to be read, and the performance history of your campaigns. Security is designed around both.

• Least privilege: only read-only metric scopes are requested, and each person sees only what their role allows.
• Minimization: no data about the people who see your ads is downloaded, only aggregated metrics.
• Defence in depth: encryption, access control, rate limits and browser protection headers act as independent layers.
• Honesty: this page describes no measure that is not actually in place.

• Passwords are stored exclusively as bcrypt hashes with a cost factor of 12. They are never kept in clear text and cannot be recovered by anyone, including us.
• A minimum length and a mix of character types are enforced when a password is created or changed.
• Two-step verification is mandatory on every sign-in. It is not optional and cannot be turned off.
• The second factor is a one-time code sent to your email address. The code expires within minutes and is invalidated as soon as it is used once.
• The code is not stored in clear text: the database keeps its hash, along with its expiry time and a used flag.
• We will never ask you for a verification code by email, phone or messaging. Anyone who does is attempting fraud.

• The session is held in a signed cookie, flagged so the browser does not expose it to scripts and only sends it over an encrypted connection.
• Each session carries a version tied to the account. Changing the password increments that version and all previous sessions stop being valid immediately.
• When an account is flagged for a mandatory password change, access is redirected to that screen until it is completed.
• There are three roles: platform administration, organization administration and client. Each has a different set of permitted routes.
• Administration routes are blocked for client accounts at the application entry point, before the request reaches the screen.
• Every route that reads or writes data verifies the session on the server and rejects the request if there is no valid session.

• All traffic between your browser and the Service travels encrypted over TLS. Unencrypted transport is not permitted.
• Advertising platform credentials are encrypted before being stored, using AES-256-GCM, an authenticated algorithm that detects any tampering with the ciphertext.
• Each credential is encrypted with its own initialization vector and stored alongside its authentication tag, so two identical credentials never produce the same ciphertext.
• The encryption key is derived from the application secret through a brute-force resistant derivation function and is not present in the source code.
• Backups and the infrastructure provider storage are kept encrypted at rest.

• Connections are always made through each platform's official flow. At no point do we ask for your password on that platform.
• Credentials are never displayed in full in the interface: they are shown masked, leaving only a fragment visible so they can be identified.
• They are not written to logs, error messages or programming interface responses.
• They are deleted immediately when the ad account is disconnected or permission is revoked from the originating platform.
• The scopes requested are read-only metric scopes. No ability to publish, edit campaigns or move budget is requested.

Each organization has its own identifier. Campaigns, metrics, clients and users are associated with it.

• Isolation is applied today at the application layer: every query that reads data is scoped to the organization identifier of the active session, and administration routes are closed to client accounts.
• Client accounts reach a separate dashboard that exposes only their own information.
• A second level of isolation inside the database itself is prepared but not yet active. It would reject any query outside the scope of the organization even if an application fault attempted it. It will be announced on this page once it is live.

Every response from the Service carries a set of headers that harden browser behaviour.

• Sending verification codes is limited per email address within a time window, which curbs automated attempts and use of the system to send unwanted mail.
• Public sign-up is limited by request origin, to prevent mass account creation.
• Once the limit is exceeded, the request is rejected with an explicit response and the block is lifted only when the window elapses.
• Syncs with the platforms respect their own usage limits and run incrementally, requesting only the periods that have changed.

• The application and the database are hosted with professional managed infrastructure providers, under a data processing agreement and acting solely on our instructions.
• Administrative access to the infrastructure is restricted to essential personnel and protected with strong authentication.
• Periodic database backups are taken, encrypted, with point-in-time restore capability.
• Software dependencies are updated regularly, prioritizing security fixes.
• Application keys and secrets are managed as environment variables and are never included in the source code or in shared documents.

• The hosting infrastructure generates server technical logs: requests, errors and response times. They are used for diagnostics and security.
• Those logs contain no passwords, verification codes or platform credentials.
• The database keeps creation and update timestamps on the main records, and deletion requests are recorded with their confirmation code, status and date.
• There is no structured audit log today capturing every action of every user. When one is implemented, it will be documented on this page.

Every advertising platform imposes security and data-use conditions on whoever connects to it. This table summarizes how we meet them.

• 1.Containment: on detecting an incident, the first step is cutting off the compromised access, invalidating sessions and, where appropriate, revoking credentials.
• 2.Assessment: we determine which data and which organizations were affected, and for how long.
• 3.Notification: if the incident affects personal data and poses a risk, we notify the affected organizations and, where applicable, the competent authority and the platforms involved, within the legal deadlines.
• 4.Remediation: the fix is applied and the measures reviewed so the same fault cannot recur.
• 5.Record: the incident, its cause and the actions taken are documented.

Part of security depends on you. Without these practices, the measures above lose effectiveness.

• Use a strong password, different from those on other services, and change it if you suspect it has been exposed.
• Protect the associated email account: whoever reaches it can receive your verification codes.
• Do not share your account or your codes with other people. Create one account per person.
• Only connect ad accounts that you own or are authorized to use.
• Revoke access for people who leave your organization and disconnect ad accounts you no longer use.
• Sign out on shared devices.

If you find a security flaw, write to [email protected] with the subject «Security». Include the steps to reproduce it and, if you have it, your estimate of the impact.

• We acknowledge receipt of the report and assess it as a priority.
• We ask that you do not publicly disclose the flaw until a fix is available.
• We also ask that you do not access third-party data, do not degrade the Service and do not run load or penetration tests without prior written authorization.
• No action will be taken against anyone researching in good faith and respecting these conditions.

Akvertising, S.A. de C.V., operator of TrackerAds.

• Security issues: [email protected].
• Privacy and exercise of rights: [email protected].
• Related documents: Privacy Notice, Terms of Service and Data deletion.