Security

Basketball Spy is built for professional basketball organizations and the security of your data is foundational to everything we build. This page describes the security practices and controls that are actually in place across the platform today, along with an honest look at the areas we are continuing to strengthen. If you have a question that isn’t answered here, please reach out.

Accounts & authentication

• Hashed passwords. Passwords are never stored in plaintext or in any reversible form. They are hashed using bcrypt before storage, and the original password is never recoverable — not even by us.
• Brute-force protection. Login attempts are rate-limited per account and per network address. Repeated failed attempts are throttled to slow down automated guessing.
• Session management. Web sessions use server-side, database-backed sessions with HttpOnly and SameSite cookie protections. Logging out fully invalidates the session and rotates its security token.
• Disabled-account enforcement. Accounts that have been disabled are blocked at sign-in and have their active sessions terminated.
• Scoped API tokens. The mobile and integration APIs authenticate with revocable bearer tokens (Laravel Sanctum). Tokens carry a configurable expiration and are deleted on logout or when they expire.

Tenant data isolation

Basketball Spy is a multi-tenant platform: every organization’s data lives logically separated from every other organization’s. This separation is enforced at the data-access layer, not left to individual screens or queries to remember.

• Enforced at the query layer. Tenant-owned records are automatically filtered to the current organization by a global query scope. There is no code path that returns another organization’s data without that filter being applied.
• Fail-closed design. If a request reaches tenant-scoped data without an established organization context, the request is refused rather than returning unscoped results. The secure default is to deny.
• Context bound per request. The active organization is resolved and bound for the lifetime of each request by dedicated middleware, and is re-evaluated on every request rather than trusted from the client.
• Shared reference data handled deliberately. Data that is intentionally shared (such as league-wide player records) uses a separate, explicit scope so that shared and private data are never conflated by accident.

Authorization & access control

• Policy-based permissions. Access to athletes, scouting reports, sessions, and lists is governed by explicit authorization policies rather than ad-hoc role checks scattered through the code.
• Least privilege by role. Administrative capabilities (managing users and settings) are gated to administrators; platform-level operations are gated separately to platform administrators.
• Granular sharing. Scouting reports and player lists use an owner / group / explicit-share visibility model, so collaborators see exactly what has been shared with them and nothing more.

Secure transport & browser protections

• Encryption in transit. Traffic is served exclusively over HTTPS/TLS. HTTP Strict Transport Security (HSTS) instructs browsers to refuse insecure connections.
• Clickjacking protection. Framing of the application by other sites is restricted (X-Frame-Options).
• MIME-sniffing protection. Browsers are instructed not to second-guess content types (X-Content-Type-Options: nosniff).
• Referrer privacy. A strict referrer policy limits how much URL information is shared with third-party destinations.
• Restricted browser features. A permissions policy opts the application out of powerful browser features it doesn’t use (such as microphone, payment, and ad-topics APIs).

Application hardening

• SQL-injection resistance. All database access goes through an object-relational mapper using parameterized queries; user input is never concatenated into SQL.
• Cross-site scripting (XSS) defense. Template output is escaped by default, so user-supplied content is rendered as text rather than executable markup.
• Cross-site request forgery (CSRF) protection. State-changing web requests require a valid anti-CSRF token.
• Mass-assignment protection. Models accept only an explicit allow-list of fields, preventing clients from setting attributes they shouldn’t.
• Server-side validation. Incoming data is validated on the server before it is processed or stored.

Data protection & backups

• Encrypted secrets. Application secrets and sensitive configuration are encrypted using AES-256.
• Automated daily backups. Tenant data is backed up automatically every day, retained for 30 days in object storage, with a tested restore path for recovery.
• Managed infrastructure. Production runs on managed, enterprise cloud infrastructure (Laravel Cloud), keeping operating systems and the underlying platform maintained and patched.

API & sync security

• Authenticated by default. Every API endpoint other than sign-in requires a valid, unexpired token.
• Token expiration & revocation. Tokens expire on a configurable schedule and are checked for expiry on each request; logging out revokes them immediately.
• Offline-sync safeguards. The mobile offline-sync bridge authenticates and establishes organization context before any data is exchanged.

Mobile app protection

• Credentials in secure hardware. On iOS and Android, sign-in tokens are stored in the device’s secure storage (Apple Keychain / Android Keystore) — they can’t be extracted without the device passcode or biometrics.
• Biometric app-lock. An optional Face ID / Touch ID lock (with passcode fallback) guards the app and re-locks shortly after it is sent to the background, so a lost or stolen device can’t be resumed straight into scouting data.
• Idle auto-logout. The mobile session is cleared after a period of inactivity, requiring full re-authentication.
• Offline-capable. The app works offline and syncs securely once a connection returns.

A modern, maintained stack

Basketball Spy is built on Laravel 13 and PHP 8.5, with security-relevant dependencies kept current. Building on a widely used, actively maintained framework means we inherit a steady stream of security fixes and battle-tested defaults rather than reinventing core protections ourselves.

Areas we’re strengthening

Security is ongoing work, and we believe in being candid about what is not yet in place. The following are on our roadmap rather than available today:

• Account-level multi-factor authentication (MFA) for an additional layer of login protection. (The mobile biometric app-lock above secures the device, not the account sign-in.)
• Encryption of offline mobile data at rest. Data cached on a device for offline use is today protected by the device lock and biometric app-lock; encrypting it fully at rest on the device is in progress.
• Expanded API rate limiting beyond sign-in, across more endpoints.
• Security audit logging to record significant account and access events.
• Formal third-party assessment. We have not yet completed an independent penetration test or a formal compliance certification (such as SOC 2). When we do, we will say so here.

Reporting a vulnerability

If you believe you have found a security vulnerability in Basketball Spy, we want to hear from you. Please email security@basketballspy.com with the details and steps to reproduce. We ask that you give us a reasonable opportunity to investigate and address the issue before any public disclosure, and that you avoid accessing or modifying data that isn’t yours while testing. We appreciate the security community’s help in keeping scouts’, coaches’, and front offices’ data safe.