security and cybersecurity

In the order we think they matter most:

1. One person reaching another's records. A coach reading another coach's clients, a client reading another client, one gym reading another. The wall is in the database, so a fault in one screen can't open it (see data security).
2. Someone signing in as you. A guessed, reused or stolen password, or a session taken from your browser.
3. A harmful script in a Trainbase page, or another site framing Trainbase to trick you into a click.
4. A leaked key that would let someone reach our services as us.
5. Bad input sent straight to our servers, skipping the app's screens.
6. A fault in a library of code we build on.

• Every entry point checks for itself. Each request to our servers checks its input, then who is signed in, then whether they may touch that record. Who you are always comes from your session, never from what the browser sends.
• Every entry point is tested as every kind of person, signed out, a stranger, the wrong role and someone from another gym, with broken values.
• The browser is told how to protect you. Every page tells the browser to use a secure connection only, never to be shown inside another site's frame, never to guess a file's type, and to send other sites only "trainbase.io" and never the page you were on. Camera and microphone are allowed only on Trainbase's own pages. A stricter content policy, naming every place a page may load code from, is running in report mode while we confirm it breaks nothing.
• Password resets and invites are limited in how often each can be sent to one address, and a coach's public join form has its own limit.
• Scheduled jobs answer only to a secret sent by our host, and refuse every call when it's missing.
• Keys stay on our servers. None is ever sent to a browser. Commits are scanned for secrets before they're saved.
• The code we build on is kept current. After our 24 October 2026 audit, we moved to the release of our web framework that cleared every critical advisory then listed against the version we ran.
• Every change to the database's rules is proven on the real database, in a transaction that is always undone, before it goes live.

• Errors are reported to us with personal details taken out first (see data security, section 7).
• Every time Trainbase support stands in a gym, and every change made while there, is logged where nobody can alter it.
• When something goes wrong we find the cause, not just the symptom. If personal information may have been exposed, our data breach response applies.

If you think you've found a security weakness in Trainbase, please tell us.

How: email hello@trainbase.io with "Security" in the subject line. Tell us what you found, where, and the steps to see it again. A screenshot helps.

What we'll do: reply to say we have it, look into it, keep you told as we fix it, and tell you when it's fixed. If you'd like, we'll thank you by name once it's fixed.

What we ask of you:

• Use only your own accounts, or test accounts we give you.
• Don't read, change, keep or delete anyone else's data. If you reach some by accident, stop, and tell us what you saw.
• Don't slow the service down for others, and don't send spam or try to trick our team or our customers.
• Give us a fair time to fix it before you tell anyone else.

If you act in good faith and keep to these, we won't take action against you for your research. We don't run a paid reward scheme.

• Use a strong password you don't use anywhere else, and never share it.
• Sign out on a shared phone or computer.
• If you think someone else has used your account, change your password and tell us straight away.
• Gym owners: when a coach or client leaves, make them inactive, so their login stops working.

No system is perfectly secure, and we don't claim Trainbase is. We hold no SOC 2 report or ISO 27001 certificate, no outside firm has tested Trainbase for weaknesses, and sign-in has no second step yet.

We review this page whenever Trainbase changes in a way that affects it, and at least once a year.