Security & Responsible Disclosure

Last updated: May 24, 2026

FRNTCOURT handles roster information, recruiting profiles, and family contact details for youth athletes. We take the security of that data seriously, and we welcome reports from independent security researchers who help us keep it safe.

1. Scope

The following are in scope for this policy:

• frntcourt.com and all subdomains we operate
• The FRNTCOURT iOS application distributed via the Apple App Store
• The REST API exposed by the FRNTCOURT server

2. Out of scope

Please do not test, report on, or include findings related to:

• Denial-of-service, volumetric, or resource-exhaustion attacks
• Social engineering of FRNTCOURT staff, users, or family members
• Physical attacks against our offices or infrastructure providers
• Findings on third-party services we depend on (Stripe, Resend, Railway, Sentry, AWS S3, Apple, Google) — please report those directly to the vendor
• Reports generated solely by automated scanners (Nessus, Nikto, etc.) with no manual validation
• Missing security headers, weak TLS ciphers, or other "best-practice" findings without a demonstrated exploit
• Self-XSS, clickjacking on pages with no sensitive state, or tabnabbing
• Email spoofing concerns absent a real impact (SPF, DKIM, DMARC tuning)
• Rate-limiting concerns (we apply rate limits where they materially help; absolute coverage isn't a goal)

3. Safe harbor

If you make a good-faith effort to comply with this policy during your security research, we will:

• Not pursue civil or criminal action against you, or notify law enforcement
• Work with you to understand and resolve the issue quickly
• Credit you publicly (with your permission) once the issue is fixed

"Good faith" means:

• You don't access, modify, or exfiltrate data that isn't your own beyond what's strictly necessary to demonstrate the vulnerability
• You don't degrade service for other users
• You don't publicly disclose the issue before we've had a reasonable chance to fix it (see §5)
• You use a test account you control where possible (you can create one for free at /pricing)

4. How to report

Email security@frntcourt.com with:

• A clear description of the issue and its impact
• Step-by-step reproduction (URLs, payloads, request/response captures, screen recordings if helpful)
• The accounts you used (we'll happily provision a test team if you don't want to use your own)
• Your preferred handle for public credit (or "anonymous" if you prefer)

For especially sensitive reports you can encrypt your email — request our PGP key in a first plaintext message and we'll send it back. We do not currently publish a key fingerprint.

5. Our commitments

• Acknowledgment within 3 business days of receipt
• Initial triage and severity assessment within 10 business days
• Fix or mitigation: critical issues within 7 days, high within 30, medium/low within 90, where reasonably possible
• Coordinated disclosure: we'll agree a disclosure date with you. Default is 90 days from initial report, sooner if a fix lands earlier
• No legal action against good-faith researchers, per §3

6. Recognition

We do not currently run a paid bug bounty. We are happy to credit researchers publicly on a forthcoming acknowledgments page (with your permission) and to provide a letter of recognition you can include in your portfolio. We may introduce a paid bounty as the platform grows; this page will be updated when that happens.

7. Existing protections

For context, FRNTCOURT applies the following defences (non-exhaustive):

• Per-IP and per-account login lockout, plus stricter limiters on signup and password-reset endpoints
• Password hashing via scrypt; new passwords are checked against the HaveIBeenPwned breach corpus
• TOTP-based two-factor authentication required for all administrator-level accounts
• Per-session CSRF tokens on all state-changing requests
• HSTS, strict Content-Security-Policy, X-Frame-Options, and related response headers
• Parameterised database queries; no string-concatenated SQL
• Path-traversal containment on local file serving; private S3 with presigned URLs for object storage
• Stripe webhook signature verification with timestamp tolerance
• Atomic database writes with on-disk backups; daily snapshot job

8. Updates

This policy may change over time. The current version always lives at frntcourt.com/security. The machine-readable companion file is at /.well-known/security.txt.