Security and compliance, in plain words.
AdLedger runs on your server, so your data never passes through ours. This page explains how it is protected, which compliance controls it ships, who is responsible for what, and the claims we won’t make.
Your data stays in your database
AdLedger is source available (FSL-1.1) and self-hosted. There is no AdLedger server in the loop and no telemetry. The only outside calls are the ones you configure: ad platforms, revenue sources, your AI model and your notification channels. Settings lists every one of them.
Who is responsible for what
When you run AdLedger, you are the data controller (and the processor). We write the software; you decide what it collects, where it runs and who can see it. That is why the controls below are switches you own, not promises we make on your behalf.
We don’t hold SOC 2 or ISO 27001 certification. Those audits cover organisations running services, not codebases, and we don’t run your install. Certification is the operator’s to pursue: AdLedger ships SOC 2-aligned controls and a mapping that shortens that work, and the project itself is not audited.
What we say, and what we don’t
Security pages are full of badges and adjectives. Here is the plain version.
| We never say | What we say instead |
|---|---|
| “SOC 2 certified”, “ISO certified” | SOC 2-aligned controls, with a mapping to ISO 27001 themes. The project itself is not audited. |
| “GDPR compliant” | GDPR-ready: built to help you meet GDPR, UK GDPR, CCPA/CPRA, ePrivacy and PECR, and India’s DPDP. When you self-host, you are the data controller. |
| “No consent needed”, “cookieless” | Consent modes are built in, including Google Consent Mode v2 glue. A cookieless mode is available, with weaker attribution. |
| “Bank-grade security” | AES-256-GCM secrets, scrypt passwords, hashed tokens, signed webhooks. |
| “HIPAA compliant” | Not designed for health data, card data or children’s data. |
| “Leak-proof” | Leaks are deterred and traceable: permissions, watermarks, fingerprints, an audit trail. |
Compliance frameworks
What AdLedger gives you for each framework, and what stays with you as the operator. The control-by-control detail is in the compliance mapping.
| Framework | What AdLedger ships | What you own |
|---|---|---|
| GDPR & UK GDPR | Subject access export and erasure per person, retention for raw events, hashed identifiers, truncated IPs, redacted payloads. | Lawful basis, privacy notice, records of processing, contracts with the tools you connect. |
| CCPA / CPRA | Global Privacy Control honoured by the pixel; export and delete per person; nothing sent to AdLedger. | Your notices and how you handle requests. |
| ePrivacy & PECR | Pixel consent modes (opt-out, consent required, cookieless) and glue for Google Consent Mode v2, Cookiebot, CookieYes, Osano and Klaro. | Your cookie banner and the mode you choose per site. |
| SOC 2 | Aligned controls: role-based access, 2FA, session limits, encryption, a tamper-evident audit log, security alerts and a posture checklist. | The audit, your policies, hosting, backups and monitoring. |
| ISO/IEC 27001 | Controls mapped to Annex A themes: access control, cryptography, logging, secure development. | Your ISMS, risk assessment and statement of applicability. |
| OWASP Top 10 & ASVS | Practices: CSP and security headers, SSRF guards, same-origin checks, constant-time signature checks, parameterised SQL. | Keeping the install updated and behind HTTPS. |
Security built in
In AdLedger today
- Roles: five built-in roles from Owner to Client, plus custom roles limited to pages and workspaces.
- Two-factor sign-in (TOTP) with recovery codes, and an org-wide “Require 2FA”.
- Sessions and devices: idle timeout, maximum lifetime, sign out one device or everywhere.
- Passwords hashed with scrypt; session and API tokens stored only as hashes.
- Connector secrets and 2FA keys encrypted with AES-256-GCM.
- Email and phone masking by role, with every reveal audited.
- A tamper-evident audit log: a hash chain with a Verify button.
- Signed webhooks, SSRF guards, and security headers including a Content Security Policy.
On the roadmap
- Passkeys and OIDC single sign-on, with no “SSO tax”.
- Rotating the encryption key with re-encryption of stored secrets.
Privacy by design
- One place for raw emails. They live in the contacts table only. Everywhere else, emails and phone numbers are SHA-256 hashes, and stored payloads are redacted.
- IP truncation. Addresses are shortened before they are stored, and the pixel doesn’t fingerprint.
- Consent modes and GPC. Opt-out, consent-required and cookieless pixel modes. Global Privacy Control is always honoured.
- Consent-aware conversion uploads. Uploads to Meta and Google carry consent signals, and contacts who said no are skipped.
- Access and erasure. Export or erase one person, plus retention rules for raw events.
- AI on your terms. Use a local model. The AI sees totals, never contacts, and the MCP server is read-only and masks emails.
Data you can’t lose, and data that can’t walk off
- Exports you control: full workspace export, and separate permissions for aggregate reports and contact lists.
- Traceable files: PDF reports carry a watermark and a fingerprint, so a leaked file can be traced to the export that made it.
- Share links that end: client links show totals only, expire, and can be revoked.
- Alerts: bulk contact exports, workspace exports, new API keys and role changes raise a security alert.
- Why we don’t block right-click: view-source, extensions and screenshots get around it, and it breaks accessibility. We make leaks traceable instead.
Supply chain
- A hardened container. The app runs as a non-root user, and npm is removed from the runtime image because the app never uses it.
- Scanning. CodeQL scans the code and workflows, Trivy scans the image, and dependency review, Dependabot and
pnpm auditwatch dependencies. - Release provenance. Release images carry an SBOM and provenance.
- Tests. Every change runs lint, type checks and the full test suite against a real database, and pull requests are reviewed in the open.
Operator hardening checklist
- Set
APP_SECRETand keep it out of the backups it protects. - Serve AdLedger over HTTPS. The bundled Caddy profile does it for free.
- Keep the database on the private Docker network.
- Give people the lowest role that works, and turn on Require two-factor sign-in.
- Keep sessions short, and verify the audit log now and then.
- Back up the database, and update regularly with
docker compose pull.
The app’s Security policy page runs this checklist against your install.
Reporting a vulnerability
Please don’t open a public issue. Use GitHub private vulnerability reporting. You’ll get an acknowledgement within 3 working days and an assessment within 10. Test against your own install only; good-faith research is welcome, and we’ll credit you in the release notes if you’d like. The full policy is in SECURITY.md.
What it isn’t for
AdLedger is not designed for health records, card data (Stripe and your checkout hold that) or children’s data. Don’t send those to it.
Licence and name
AdLedger is licensed under the Functional Source License (FSL-1.1-ALv2): free to use and self-host, with the full source available to read and audit. It can't be sold or offered as a competing product or hosted service, and each version converts to Apache-2.0 two years after its release. You can use the name for your own install; a public fork should use its own name.