Security
Last updated August 14, 2026
A plain-language account of how Fightprint actually protects data today — written for a procurement or security review, not a marketing page. Fightprint is an early-stage product built and operated by a small team (Graylight Creative). We'd rather tell you exactly what's true, including the gaps, than write something that sounds more mature than the product is.
Passwords are hashed with PHP's standard password_hash() (bcrypt) before they're ever written to the database. We do not store passwords in plain text, log them, or have any way to look up or recover a user's actual password — resetting is the only recovery path, by design.
The minimum password length is 8 characters. We don't currently force additional complexity rules (a mandatory symbol or number, for example) — length plus hashing plus a rate-limited login endpoint is where the actual protection comes from, not composition rules.
Login failures are rate-limited per account (5 failed attempts per 15 minutes) and per network (20 failed attempts per 15 minutes, looser because a gym's shared wifi can mean several people mistyping a password). Registration is rate-limited per network (10 attempts per hour). Password-reset requests are rate-limited both per account and per network (5 per hour each).
Login responses are deliberately identical — in message and in timing — whether an email doesn't exist or the password is wrong, so the login endpoint can't be used to enumerate which emails have accounts.
Session tokens are 256-bit values generated with PHP's cryptographically secure random source. Only a SHA-256 hash of the token is ever stored — the raw token exists only in the response returned once at login, never written to a log or the database again. Sessions expire after 30 days, and resetting a password immediately revokes every other active session on that account. Password-reset links are single-use and expire after 45 minutes.
fightprint.app is served exclusively over HTTPS, with a Let's Encrypt certificate that renews automatically. Any request to the plain HTTP port is redirected to HTTPS — there is no path where traffic to the app travels unencrypted.
We do not currently apply independent field-level or full-disk encryption to data at rest beyond what the hosting infrastructure provides by default. The one field we treat as fully irrecoverable rather than merely encrypted is the password, which is hashed as described above.
Fightprint runs on a single server, operated by Graylight Creative — the same team that built the product. It is not distributed across multiple regions or availability zones, and there is no automatic failover to a second server today. If that single server has a hardware or hosting-level outage, the product goes down until it's resolved. We think it's more useful to say that plainly than to imply enterprise-grade redundancy that isn't there yet.
The database (MySQL) runs on that same server rather than as a separately managed database service. It is not reachable from the public internet — the only network path to it is local to the server itself or over a private administrative network, not exposed on the open web.
The server runs a host firewall with a default-deny posture on inbound traffic, allowing only the ports the product actually needs. There is no dedicated web-application-firewall (WAF) product sitting in front of the app today. Internal tooling that isn't meant for customers — an expert-review console used by our own team — is gated behind HTTP Basic Auth at the web server, separately from the authentication system customers use.
Files that should never be served directly (environment/configuration files, version control history, dependency and storage directories) are explicitly blocked at the web server layer, independent of anything in the application code.
The production database is backed up automatically every night via an automated mysqldump, compressed, and retained for 14 days on a rotating basis. This runs as a scheduled job independent of any person remembering to do it. A separate, broader nightly process also captures this database as part of a wider backup routine and stores an additional copy off the server — so there is more than one copy of this data in more than one place, not just the 14-day local rotation.
We have not published a formal recovery-time or recovery-point commitment (an "RTO/RPO"), and restoring from backup has not been run through a customer-facing drill. If that level of formality is a requirement for your process, tell us and we'll scope it honestly rather than promise a number we haven't tested.
Every unhandled exception anywhere in the request lifecycle is caught by a central handler, logged, and reported to an internal error-tracking service (an internal tool called Blackbox, operated by Graylight Creative) so the team sees failures — including ones that never reach a support inbox — in near real time. This is operational error monitoring: it tells us when something breaks. It is not a dedicated security event monitoring / SIEM system watching for intrusion patterns, and we don't want to describe it as more than it is.
We do not have a formal, written incident response plan today. That's an honest gap for a product at this stage, not something we're going to paper over with a document nobody has actually run through. If something goes wrong, our commitment is to investigate promptly, fix it, and tell affected customers directly and honestly what happened — but there isn't yet a documented playbook with defined roles, escalation paths, or response-time targets. Building one is on our list as the product moves upmarket into institutional customers.
Fightprint uses exactly one third-party data processor: Burst, an email relay operated by Graylight Creative that sends through SendGrid on our behalf, on a domain-authenticated sending channel (DKIM/SPF/DMARC configured for fightprint.app). It is used solely to deliver transactional email — password-reset links, and an optional welcome message if someone subscribes to updates. It does not receive or process any training data, and it isn't used for marketing analytics or tracking. No other third party processes personal data on Fightprint's behalf. We don't run ad pixels, third-party analytics scripts, or sell data to anyone.
To be direct: Fightprint has not completed a SOC 2 audit, does not hold ISO 27001 or any other formal security certification, and has not been through an independent third-party security audit. If a certification is a hard requirement for your procurement process, we'd rather hear that now than have it come up as a surprise later — happy to talk through what's actually needed and what a realistic timeline looks like.
For a security questionnaire, a call with our team, or anything not covered here: [email protected] or [email protected].
