Security

1.At a glance

Data location

Helsinki, Finland (EU) — European Union

Hosting provider

Hetzner Online GmbH (ISO/IEC 27001 certified site)

Transport

HTTPS with TLS everywhere, HSTS enabled

Two-factor auth

TOTP, with automatic lockout on repeated failures

Single sign-on

Google and GitHub; OIDC/SSO arranged individually on Enterprise

Tenant isolation

Enforced per query, covered by an automated test suite

Card data

Never touches our systems — hosted checkout only

Vulnerability reports

[email protected]

The same control list forms Annex 2 of the Data Processing Addendum, so what you read here is what we are contractually bound to.

2.Where your data is

All production systems — the application, the API, the telemetry endpoint, PostgreSQL, ClickHouse and object storage — run on infrastructure operated by Hetzner Online GmbH in Helsinki, Finland (EU). That is inside the European Union.

The provider maintains an ISO/IEC 27001 certified information security management system covering that site, and physical security, power and environmental controls are its responsibility under a data processing agreement we hold with it.

Cloudflare sits in front as DNS, CDN and edge security, which means connection metadata passes through its global network. Every other provider we use is listed, with its location and transfer mechanism, on the subprocessors page.

3.Encryption in transit

• Every public endpoint — tracepath.dev, app.tracepath.dev, ingest.tracepath.dev, docs.tracepath.dev — is served over HTTPS with TLS. Certificates are issued and renewed automatically.
• HTTP Strict Transport Security is applied, so browsers refuse to fall back to plaintext after the first visit.
• Telemetry is accepted over OTLP/HTTP via HTTPS (protobuf or JSON, optionally gzipped). There is no plaintext ingest path on the hosted service, and no OTLP/gRPC listener.
• Internal traffic between the application, the identity service, PostgreSQL and ClickHouse runs on a private network that is not reachable from the internet.

4.Authentication

• Password storage. Passwords are never stored in readable form. They are stored only as salted hashes produced by a deliberately slow function — bcrypt with a work factor of 12 in the application backend, and the hashing provided by the authentication framework in the identity service.
• Email verification. A new account must verify its email address before it becomes usable. Verification links expire after one hour.
• Two-factor authentication. Time-based one-time passwords (TOTP) are supported, compatible with any standard authenticator app. Repeated failed second-factor attempts lock the account automatically for a configured period.
• Single sign-on. Optional sign-in with Google or GitHub. Sign-in through your own OIDC identity provider is not self-serve: it is arranged individually on the Enterprise plan, by agreement, and configured by us for your account.
• Password reset. Reset links are single-use and expire after one hour. Completing a reset revokes existing sessions, so a stolen session does not survive a password change.
• Sign-up abuse protection. Cloudflare Turnstile is applied at sign-up where configured, and sensitive endpoints are rate limited independently of it.

5.Sessions, tokens and API keys

• Session tokens. Dashboard sessions use JSON Web Tokens signed with RSA keys published through a JWKS endpoint. Keys rotate on a schedule with a grace period so rotation never signs users out. The verifier pins the signature algorithm and requires a key identifier; a token signed with an unknown key is rejected rather than trusted after a refresh, which closes the classic algorithm-confusion class of attack.
• Refresh tokens. Stored hashed, never in readable form, and organised in families so that reuse of an already-rotated token is detectable.
• Personal access tokens. Shown once at creation and then stored only as a SHA-256 hash alongside a non-secret prefix, so a database read cannot yield a usable token. Each token can carry an expiry, records its last use, and can be revoked individually.
• Ingest keys. Project ingest tokens are scoped to a single project. If one leaks, rotate that project’s token without affecting anything else.
• Internal service calls. Webhooks between our own services are authenticated with an HMAC-SHA256 signature computed over a timestamp and the raw request body, compared in constant time, with a narrow replay window and a request size cap. An unsigned or stale call is refused.

6.Authorisation and tenant isolation

• Role-based access control. Permissions are granted at organisation level and can be narrowed per project. Dedicated middleware checks organisation membership, project access, write access, administrative rights and operator rights on every protected route, rather than leaving the check to individual handlers.
• Isolation by construction. Every data access path is scoped to the organisation making the request. There is no code path that reads telemetry without an organisation scope.
• Isolation is tested, not assumed. A dedicated cross-tenant test suite attempts to read and write another tenant’s data across the API surface and fails the build if any attempt succeeds. It runs as part of the backend test suite, so a regression breaks CI rather than reaching production quietly.
• Least privilege for people too. Invite users with the narrowest role that lets them do their job, and remove them when they leave. Seats are per named individual for exactly this reason.

7.Audit trail and administrative access

• Administrative actions taken by the operator are written to an append-only audit table recording who acted, what they did, on what target, and when.
• Operator privilege is read from the database at request time, not taken from a token claim, so a forged or stale token cannot assert it.
• Sessions created through administrative impersonation are explicitly rejected by privileged routes — an impersonated session cannot be escalated into an operator action.
• We do not read the contents of your projects except when you ask us to help with a specific problem, or when it is strictly necessary to keep the Service running or respond to a security incident.
• There is no self-serve, per-organisation audit log in the dashboard today. Export of the administrative audit records that concern your organisation is available on request at [email protected], and is arranged individually by agreement on the Enterprise plan.

8.Platform hardening

9.Payment data

Card details are entered directly into Stripe’s hosted checkout and are handled entirely by Stripe. TracePath never receives, transmits or stores a card number, and our systems are not a cardholder data environment.

What we store is the Stripe customer and subscription identifier, your plan, billing period and invoice history. Payment methods are managed by you in the Stripe billing portal.

Stripe webhooks are verified against Stripe’s signature before being acted on, and every event is recorded once by its Stripe event identifier so a replayed webhook cannot double-apply.

10.Retention and deletion

• Telemetry retention is enforced by the storage layer itself, through time-to-live policies on the telemetry tables, rather than depending on an application job that might not run.
• Stored session replay recordings are additionally swept from disk by a scheduled cleanup job, and expired authentication tokens are purged.
• Retention per plan and what happens on termination are set out in the Terms and the Privacy Policy.
• Short retention is a security control as well as a cost control. Data you no longer hold cannot be breached.

11.How we build

• All changes go through version control and review before reaching production.
• The backend, frontend and identity services have automated test suites, including the cross-tenant isolation suite described above, and they run in continuous integration.
• The Go modules behind the backend and the CLI are scanned for known vulnerabilities with govulncheck, daily and on every change to them, in continuous integration. The JavaScript dependency trees of the dashboard, the identity service and this website are not yet covered by automated scanning — we update them by hand and are wiring scanning in.
• Secrets are supplied through environment configuration and are never committed to the repository.
• Production access is limited to the operator and is recorded.

12.Incident response

• If we become aware of a personal data breach affecting customer data, we notify affected customers without undue delay and in any event within 48 hours, with the information they need to meet their own obligations. The commitment is contractual — section 10 of the DPA.
• Where the GDPR requires it, we notify the supervisory authority within 72 hours.
• We tell you what we know when we know it, in phases if necessary, rather than waiting for a complete picture.
• We do not notify regulators or data subjects on your behalf: as controller, that decision is yours.

13.What you control

In an observability platform, the most effective security control is the one you apply before data leaves your systems. We cannot apply it for you.

• Mask session replay. Without masking, replay captures what your users see and type. Configure it before enabling replay in production.
• Scrub attributes and headers. Authorization headers, cookies, tokens and query parameters carrying identifiers should be stripped at the SDK, not stored and regretted.
• Keep identifiers out of log bodies and span names. Structured attributes you can filter beat free text you cannot.
• Set the shortest retention that meets your operational need.
• Enforce two-factor authentication and review your member list regularly.
• Rotate ingest keys and personal access tokens when someone leaves or a token may have been exposed.

14.What we do not claim

Diligence is only useful if the gaps are visible too. As at the date on this page:

• No third-party certification or audit report. TracePath does not hold SOC 2, ISO/IEC 27001 or any equivalent certification of its own, and there is no independent penetration test report available. Our hosting provider is ISO/IEC 27001 certified for its data centres; that is the provider’s certification, not ours, and it does not extend to our application. We answer security questionnaires in writing instead, and section 12 of the DPA gives you an audit right.
• No HIPAA, PCI DSS or FedRAMP compliance claim. The Service is not certified or assessed under any of these programmes. We do not offer a Business Associate Agreement today, on any plan, and we will not imply otherwise. Do not send protected health information or cardholder data to TracePath.
• No application-level encryption at rest. Data is stored on the hosting provider’s infrastructure and protected by the access controls described above. We do not currently operate our own encryption-at-rest layer or customer-managed keys. If your threat model requires them, talk to us before you commit.
• Backup and disaster recovery are being built. Backup tooling and restore runbooks exist in our repository but are not yet operating on production. Until we can state a verified recovery point and recovery time objective, backed by a completed restore drill, we make no backup or recovery commitment here. Treat TracePath as an observability platform rather than a system of record, and keep your own copies of anything you cannot afford to lose. We will update this page when the position changes.
• No contractual uptime SLA outside Enterprise. We aim for high availability and publish no number we have not measured. Service level commitments are agreed individually on Enterprise plans.
• No bug bounty programme yet. We do not currently pay for vulnerability reports. We do credit reporters who want to be credited, and we respond to every report.

15.Reporting a vulnerability

If you have found a security problem in TracePath, we want to hear about it before anyone else does.

Report to

[email protected]

Acknowledgement

Within 3 business days

Initial assessment

Within 10 business days

Disclosure

Coordinated — we agree timing with you, normally within 90 days

What to include

A description of the issue, the affected endpoint or component, the steps to reproduce it, what an attacker could achieve, and anything you need to be credited by. Proof-of-concept code helps. Send it in plain text; if you need to encrypt it, ask us first and we will arrange a channel.

Safe harbour

We will not pursue legal action, and we will not ask your hosting provider to act against you, for security research that follows these rules:

• test only against accounts, organisations and data that are yours, or that you have written permission to test;
• do not access, modify, exfiltrate or destroy another customer’s data — if you encounter it accidentally, stop, do not save it, and tell us immediately;
• do not degrade the Service: no denial-of-service testing, no load testing, no automated scanners running at volume;
• no social engineering of our people or our providers, no phishing, no physical attacks;
• give us a reasonable opportunity to fix the issue before disclosing it publicly, and do not disclose customer data at any point;
• comply with applicable law.

Research that stays inside those bounds is authorised under the Acceptable Use Policy. Research outside them is not.

Out of scope

• Reports from automated scanners with no demonstrated impact, and best-practice findings such as missing headers on static pages with no exploitable consequence.
• Issues requiring a fully compromised device, a rooted or jailbroken client, or physical access to a user’s machine.
• Social engineering, spam, and email configuration findings with no practical impact.
• Vulnerabilities in third-party services — please report those to their owners.
• Denial of service through sheer volume.

Credit

We are happy to credit reporters publicly once an issue is fixed, if you want that. Tell us how you would like to be named.