Security at KeepInTracks

Shared infrastructure, separate workspaces

KeepInTracks Business uses a shared application service and database. Each business is a tenant: its records are associated with its workspace. This is logical isolation on shared infrastructure, rather than a dedicated server or database for each business.

The server identifies the workspace from the requested hostname, including registered custom domains. A tenant ID supplied by the browser is not enough to select or access another workspace.

Access checks on the server

For protected business requests, the server verifies the sign-in token, checks active membership in the workspace identified by the hostname, and checks the permissions required for the action. Domain services restrict data operations to that workspace using tenant filters and ownership checks.

Where row-level security applies

PostgreSQL row-level security policies restrict access on database paths that use roles subject to those policies. The application server uses a privileged database role that bypasses row-level security, so its requests rely on the server-side membership, permission and tenant-scope checks described above.

The repository includes tests for database row-level security and separate tests for server-side tenant isolation. These check different access paths.

How to report

Email security@keepintracks.com. Please include a description of the issue, the affected product or URL, clear reproduction steps, and the potential impact. English and French are both fine.

If the issue is urgent or sensitive, say so in the subject line and we will prioritise it. If you prefer encrypted mail, ask us for a key first.

Scope

In scope: the marketing site keepintracks.com, the KeepInTracks Business and Personal apps, the Support Admin, the customer portal, the hosted storefront, the public status site, and their public APIs under *.keepintracks.com.

Out of scope: third-party infrastructure we do not operate (for example Supabase, Stripe, Plaid, Cloudflare, Twilio), social engineering or phishing, physical security, denial-of-service attacks, and reports that only note missing headers, SPF/DKIM/DMARC configuration, or version disclosure without demonstrable impact.

Rules of engagement

Do not access, modify, or exfiltrate data beyond what is needed to demonstrate the vulnerability. Use test or throwaway accounts where possible.

Do not disrupt production services, degrade availability, or run automated scanning that generates significant traffic. If you are unsure whether a test is acceptable, ask first.

Stop testing and contact us immediately if you encounter personal information belonging to another person.

Safe harbor

Good-faith testing conducted in accordance with this policy will not be treated as unauthorized access, provided you made a genuine effort to avoid harm and privacy violations, reported the issue promptly, and did not publicly disclose it before resolution.

This safe harbor does not cover testing of systems owned by third parties, or activity that violates applicable law.

What we will do

We aim to acknowledge your report within five business days and to keep you informed as we triage and fix it. We will credit you in our release notes or on this page unless you ask us not to, and we will coordinate public disclosure timing with you.

We will treat your report confidentially and will not share your identity without your consent.

Coordinated disclosure

Please give us a reasonable window to investigate and fix before publishing details — normally up to 90 days. If we are unresponsive for a sustained period, you may disclose the issue as you see fit. We ask that you do not publish exploit code or working examples while a fix is still rolling out.

Contact

Security contact: security@keepintracks.com. This page is also available in French at /fr/security.