Security
last updated July 23, 2026
Our security posture
YouthPerformance is built for youth athletes and their families. We minimize what the public training service collects, keep advertising and cross-site tracking off youth surfaces, and treat security and privacy controls as launch requirements rather than optional add-ons.
- The public plan flow does not request a name, email address, date of birth, payment card, or free-text health information.
- Browser and service-worker boundaries keep authenticated, bearer-token, API, and sensitive media responses out of public caches.
- Transport and browser protections include HTTPS, a restrictive Content Security Policy, HSTS on the verified apex, clickjacking protection, and a restrictive Permissions Policy.
- Dependencies, privacy invariants, legal launch conditions, and public-route behavior are checked in the build and test pipeline.
- Identifiable Athlete Passports remain disabled until parent consent, certified custody, monitoring, retention, and deletion gates are satisfied.
This summary describes current design controls. It is not a guarantee that the service has no vulnerabilities.
Report a vulnerability
The dedicated vulnerability-disclosure mailbox is awaiting operator activation. Do not send sensitive vulnerability details through general support or privacy channels. The monitored mailbox will be published here before this policy is released.
If you encounter personal information, stop testing, do not download or retain it, and report only the minimum detail needed for us to locate and contain the issue.
Good-faith research
We welcome research intended to improve the security of YouthPerformance. To stay within this policy:
- Test only systems owned and operated by YouthPerformance, not third-party provider infrastructure.
- Use your own accounts and synthetic data; never access, modify, delete, or retain another person’s data.
- Avoid denial of service, automated high-volume traffic, social engineering, phishing, physical testing, malware, persistence, or destructive actions.
- Stop as soon as you confirm the issue. Do not move laterally, establish persistence, or test beyond what is needed to demonstrate impact.
- Give us a reasonable opportunity to investigate and remediate before public disclosure, and coordinate timing when user safety could be affected.
- Comply with applicable law and these boundaries. This policy does not authorize testing of anyone else’s systems or data.
When research follows these boundaries and is reported promptly in good faith, YouthPerformance will treat it as authorized security research and will not initiate legal action based solely on that research. If a third party brings legal action, we will make our authorization known where appropriate.
What happens after a report
- We confirm receipt after the monitored disclosure channel is active.
- We triage severity, affected data and systems, exploitation risk, and immediate containment needs.
- We keep the reporter informed at meaningful milestones when it is safe and lawful to do so.
- We coordinate remediation and disclosure timing. We may need to limit detail while an issue remains exploitable or an investigation is active.
YouthPerformance does not currently operate a bug-bounty or paid reward program. Acknowledgment is at our discretion and only with the reporter’s permission.
Machine-readable policy
Researchers and automated tools can find the canonical RFC 9116 file at /.well-known/security.txt.