Security

How Scouting Spy protects your organization's data

Scouting Spy is built for professional and college sports 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.

Accounts and 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. Tokens carry a configurable expiration and are deleted on logout or when they expire.

Tenant data isolation

Scouting 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 and team records, uses a separate, explicit scope so that shared and private data are never conflated by accident.

Authorization and access control

• Policy-based permissions. Access to players, scouting reports, schedules, and lists is governed by explicit authorization policies rather than ad-hoc role checks scattered through the code.
• Least privilege by role. Administrative capabilities, such as 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, and explicit-share visibility model, so colleagues see exactly what has been shared with them and nothing more.
• AI access is opt-in and per person. Connecting an AI assistant is something an individual scout chooses to do through a consent screen. Nothing is connected by default, an assistant can only act within that scout's own permissions, and the connection can be revoked at any time.

Secure transport and browser protections

• Encryption in transit. Traffic is served exclusively over HTTPS. HTTP Strict Transport Security instructs browsers to refuse insecure connections.
• Clickjacking protection. Framing of the application by other sites is restricted.
• MIME-sniffing protection. Browsers are instructed not to second-guess content types.
• 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 does not use, such as the 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 defense. Template output is escaped by default, so user-supplied content is rendered as text rather than executable markup.
• Cross-site request forgery protection. State-changing web requests require a valid anti-forgery token.
• Mass-assignment protection. Models accept only an explicit allow-list of fields, preventing clients from setting attributes they should not.
• Server-side validation. Incoming data is validated on the server before it is processed or stored.

Data protection and 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, keeping operating systems and the underlying platform maintained and patched.

API and sync security

• Authenticated by default. Every API endpoint other than sign-in requires a valid, unexpired token.
• Token expiration and 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, the Apple Keychain or Android Keystore. They cannot be extracted without the device passcode or biometrics.
• Biometric app-lock. An optional Face ID or 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 cannot 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

Scouting 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 are 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 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.