Security
Athlete health data deserves walls that hold when software fails politely. This page describes the protections actually built into Strong today: where they live, what they enforce, and how they are proven.
This page describes the security posture of the product as built, verified against the codebase on the date above. It is maintained by the team and will be reviewed alongside the legal pages before general availability.
The posture in one paragraph
Strong's security model is enforced in the database, not in the interface. Every table carries row-level security, so what a signed-in person can read or write is decided by Postgres itself on every single row, based on who they are and what role their organisation gave them. A user interface bug cannot leak what the database refuses to return.
Tenant isolation
Each organisation's data is invisible to every other organisation. Beyond the row-level policies, every athlete-linked record carries a composite reference to both the athlete and the organisation, so a record cannot even be created against an athlete outside its own organisation: the database rejects the row. Isolation is structural, not a filter added per query.
Role walls
Within an organisation, access follows a ratified role matrix, enforced by the same row-level policies:
- A coach reads an athlete's availability status, never the diagnosis or medication record behind it.
- Clinical writes (injuries, medications, availability decisions) belong to medical staff.
- Administrative roles are walled out of clinical data entirely.
These walls are proven from the hostile side: the test suite signs in as the role being locked out and watches the database refuse the read or write, for every cell of the matrix.
Append-only audit trail
Every governed write, to a medication record, an injury, an availability decision, or a supplement log, lands in an audit trail that records who acted, what they did, and when. The trail is append-only at the database level: any attempt to update or delete an audit entry is refused by the database itself, whoever asks.
Integration credentials
When an organisation connects a device platform such as Polar or Whoop, the OAuth tokens Strong receives are encrypted with AES-256-GCM before they are stored, with support for encryption key rotation. The tokens are decrypted only in the server process that calls the provider. They never reach a browser, and they never appear in a log line.
The two-key boundary
The application talks to the database with two credentials: a public one that is useless without a signed-in session and is bounded by row-level security, and a privileged server-side one used only by background jobs. The privileged key is walled off from browser code by the build itself: an automated check fails the build if any code path could deliver it to a client.
Logging and health data
No secret, token, or personal health detail is written to logs, error messages, or client responses. Internal failures map to safe messages for the person on screen; the diagnostic detail stays server-side. Every call Strong makes to an external provider carries a bounded timeout, so a hanging third party cannot hang the platform.
What we do not claim
Strong holds no SOC 2 or ISO 27001 certification today, and this page will not imply otherwise. The platform is in early access; formal certification is a matter of when the business stage justifies the audit, not of the engineering posture described above, which is already built and tested. If a certification claim ever appears on this page, it will be because the certificate exists.
Reporting a vulnerability
If you believe you have found a security issue in Strong, tell us at hello@strong.app and include enough detail to reproduce it. We read these first and will respond directly. Please do not test against organisations' real data.