Security

This page describes the controls that protect telemetry you send to TracePath Cloud, written for the engineer doing the integration. It ends with what TracePath does not have, because a security page that lists only strengths is no use to anyone doing real diligence.

The contractual version of the same material is the Security page (opens in a new tab) on the marketing site, whose control list forms an annex of the Data Processing Addendum (opens in a new tab).

Where your data is

All production systems — the dashboard, the API, the ingest endpoint, PostgreSQL, ClickHouse and object storage — run on infrastructure operated by Hetzner in Helsinki, Finland, inside the European Union.

Cloudflare sits in front as DNS, CDN and edge protection, so connection metadata passes through its global network. Every provider that touches TracePath data is listed, with its location and transfer mechanism, on the subprocessors page (opens in a new tab). That page is the authoritative list; this one does not duplicate it.

Encryption in transit

• tracepath.dev, app.tracepath.dev, ingest.tracepath.dev and docs.tracepath.dev are served over HTTPS with TLS. Certificates are issued and renewed automatically.
• HTTP Strict Transport Security is applied, so browsers refuse a plaintext fallback after the first visit.
• Responses carry X-Content-Type-Options: nosniff and a Content Security Policy; dashboard responses are additionally frame-ancestors 'none'.
• Telemetry is accepted over OTLP/HTTP on the ingest host only. There is no plaintext ingest endpoint and no gRPC endpoint.

Authentication

• Passwords are hashed with bcrypt (cost 12) and never stored or logged in readable form.
• Two-factor authentication uses TOTP. The sign-in flow challenges any account that has it enabled, and repeated failed codes lock the attempt out automatically (five attempts, then a 15-minute lockout by default). Self-serve enrolment is not yet exposed in the dashboard — see what TracePath does not have.
• Sign-in with Google or GitHub is offered where enabled; the buttons on the sign-in page are the authoritative list.
• Dashboard sessions are JWTs signed server-side with HMAC-SHA-256 and a secret that never leaves the backend. The verifier pins the algorithm, so a token presented with any other alg — none included — is rejected rather than trusted. A session token expires 7 days after it is issued.
• Refresh tokens are stored hashed and grouped into families, so reuse of an already-rotated token is detectable, and a sign-out revokes the whole family server-side.
• Authentication endpoints — sign-in, password reset, invitation acceptance, the device-code flow — carry per-IP rate limits.

The credentials you hold

Project tokens carry no user identity. They are 32-character hex strings scoped to a single project, and anyone holding one can write telemetry into that project — so keep them in environment variables and out of source control and client-side bundles you do not control. Organization members with the read-only role never see them.

Personal access tokens are shown once at creation and then stored only as a SHA-256 hash next to a 12-character prefix, so reading the database yields nothing usable. Each one can carry an expiry (1 to 3650 days), records its last use, and can be revoked individually without affecting your other tokens or your browser session. See API reference.

Authorization and tenant isolation

• Permissions are granted at organization level — owner, admin, user, read-only — and can be narrowed per project.
• Dedicated middleware checks organization membership, project access, write access and administrative rights on every protected route, rather than leaving the check to individual handlers.
• Every telemetry read is scoped to the requesting organization. There is no code path that reads telemetry without an organization scope.
• Isolation is tested, not assumed. A cross-tenant suite drives one organization's principals — owner, admin, member and read-only — at another organization's resources across the route surface, and fails the build if any attempt returns foreign data. It runs in CI on every change, so a regression breaks the build rather than reaching production quietly.

Administrative access

• Actions taken by a TracePath operator are written to an append-only internal audit table recording who acted, on what, and when.
• Operator privilege is read from the database at request time rather than taken from a token claim, so a forged or stale token cannot assert it.
• Sessions created through administrative impersonation are rejected outright by privileged routes, so an impersonated session cannot be escalated.
• We do not read the contents of your projects except when you ask us to help with a specific problem, or where it is strictly necessary to keep the service running or to respond to a security incident.

Ingest hardening

The ingest path is the one endpoint that accepts unauthenticated-by-user traffic at volume, so it is bounded deliberately:

The 503s are retryable answers that an OTLP exporter backs off from rather than failures it drops the batch on. 413 and 401 are permanent: exporters treat 4xx as final and discard the batch, so neither is something to retry into.

Payment data

Card details never reach TracePath's systems. Checkout and the customer portal are hosted by Stripe, and the only billing data TracePath stores is account metadata — customer and subscription identifiers, plan code and period. Stripe webhooks are verified by signature over the raw request body and applied idempotently per event id.

What you control

• Do not send what you do not want stored. Scrub secrets, tokens and personal data before export — an OpenTelemetry attribute processor or a Collector in front of TracePath is the right place for it. TracePath stores the attributes you send.
• Bound what a profile can carry. A project's profile label allowlist limits which labels are kept on ingested profiles, so an unexpected label cannot smuggle data in.
• Drop healthchecks at ingest so liveness probes do not fill your dashboards — see Healthchecks.
• Invite people with the narrowest role that lets them do their job, and use per-project overrides where an organization-wide role would be too broad.
• Remove members when they leave. Seats are per named individual for exactly this reason.

What TracePath does not have

As of this page:

• No certification of our own. No SOC 2, no ISO/IEC 27001, no independent penetration-test report. Our hosting provider holds ISO/IEC 27001 for its data centres; that is its certification, not ours, and it does not extend to the application. We answer security questionnaires in writing instead.
• No HIPAA, PCI DSS or FedRAMP claim. Do not send cardholder data or protected health information. A Business Associate Agreement is only ever discussed as part of an Enterprise scoping conversation.
• No application-level encryption at rest and no customer-managed keys. Data is protected by the access controls above, not by an encryption layer we operate.
• No per-tenant OIDC single sign-on in TracePath Cloud, no customer-facing audit log or audit export, no dedicated single-tenant deployment, and no cold-storage or data-export API. None of these ship in the product today. Where a plan comparison mentions one, it means something to be scoped individually on Enterprise, not a switch we can turn on.
• No self-serve two-factor enrolment. TOTP is enforced at sign-in for accounts that have it, but there is no screen in the dashboard to turn it on yet. Ask support if you need it before it ships.
• No verified backup or recovery commitment yet. Treat TracePath as an observability platform, not a system of record, and keep your own copy of anything you cannot afford to lose.
• No contractual uptime SLA outside Enterprise, and no published availability number we have not measured.
• No bug bounty programme. We do not pay for reports. We do answer every one, and we credit reporters who want to be credited.

Reporting a vulnerability

Send security reports to [email protected] — not to support, and not to a public channel.

Include the affected endpoint or component, steps to reproduce, what an attacker could achieve, and how you want to be credited. Proof-of-concept code helps. The full safe-harbour terms are on the security page (opens in a new tab): we will not pursue legal action over good-faith research that follows them.

Please do not test against other customers' data, do not run denial-of-service or volumetric tests against the ingest endpoint, and use your own organization and projects for anything you try.