RepRoom Security Overview

Last updated: 5/4/2026

This document describes the security practices currently in place at RepRoom. We treat it as a living document and update it as our practices evolve. For questions, contact security@reproom.dev.

1. Architecture summary

RepRoom is a single-application web service built on a modern, US-hosted stack:

• Application framework: Next.js (App Router), TypeScript, deployed on Vercel
• Database: PostgreSQL hosted on Supabase
• Authentication: Auth.js (NextAuth) with credentials provider, JWT session strategy
• Rate limiting: Upstash Redis (sliding window)
• Payments: Stripe (PCI DSS Level 1)
• Email: Resend
• Source control: Private GitHub repository

A complete subprocessor list, including hosting regions and certifications, is published at reproom.dev/subprocessors.

2. Encryption

In transit. All connections to RepRoom use TLS. HTTP requests are redirected to HTTPS at the platform edge. Internal connections from RepRoom's application layer to its database and other infrastructure are also encrypted.

At rest. Database storage is encrypted at rest by Supabase using AES-256. Database backups are encrypted by the same mechanism. Secrets and environment variables are stored in Vercel's encrypted environment configuration; no secrets are committed to source control.

3. Authentication and access control

Passwords. User passwords are hashed using bcrypt with a cost factor of 12. Plaintext passwords are never stored, logged, or transmitted to any system other than the bcrypt hashing step at signup or password change. Password fields are never returned in API responses.

Sessions. Sessions are issued as JWTs by Auth.js. Cookies are set with httpOnly, Secure, and SameSite attributes. Sessions are validated on every authenticated request against the user's current state (including soft-delete status), so a soft-deleted user immediately loses access regardless of any active session.

Email verification. Email addresses are verified on signup for accounts created through the standard signup flow. Unverified users can access their account but cannot send messages, post announcements, or join teams until verification is complete. Verification emails can be resent, subject to rate limiting.

Email verification does not apply to under-13 athletes onboarded through the school-authorized path, because no email address is collected from those accounts. Authorization for those accounts is established through the institution's signed Data Privacy Agreement and the coach-generated claim code, as described in Section 3.1.

Age gate. A 13+ age confirmation is required at standard signup, enforced server-side on the signup API. Submissions without explicit age confirmation are rejected with a 400 response. The standard signup flow does not knowingly create accounts for users under 13.

Role-based access control. RepRoom enforces access control at three layers:

1. Request gate: an application-level proxy redirects unauthenticated traffic and routes authenticated users based on role (institution administrator, coach, athlete)
2. Layout-level checks: server-side session checks block unauthenticated access to dashboard surfaces
3. Service-layer checks: every team-scoped or institution-scoped operation verifies membership and role before reading or modifying data

Coach-level access is scoped to teams the user is a member of. Athlete-level access is scoped further by the athlete's groups, tags, and positions within their team. Institution administrator access spans all teams within the administrator's institution; this scope is documented in our Privacy Policy.

Account deletion. Users can delete their own accounts from account settings. Deletion is enforced as follows:

• The user's account is soft-deleted immediately in the same database transaction as the API response
• The user's athletic profile (including height, weight, birthday, and similar personal information) is soft-deleted at the same time
• Team, group, and tag memberships are soft-deleted at the same time
• If the user is a head coach, their teams and rosters are deactivated together with the account
• If the user is the sole Primary Administrator of an institution, deletion is blocked until that role is transferred — preventing institutions from being orphaned
• A scheduled hard-delete process for soft-deleted accounts is on the active development roadmap, expected within Q3 2026
• Personal information may be permanently removed beyond standard deactivation by emailing privacy@reproom.dev, fulfilled within 30 days
• Under-13 athlete accounts may be deleted on request from the athlete's institution, parent, or guardian, with permanent deletion of personal information completed within 30 days of a verified request

Internal access to production data. Access to production data is limited to authorized RepRoom personnel who need it to operate, support, or secure the Service. Access is mediated by authenticated provider accounts (Supabase, Vercel, GitHub, Stripe, Resend, Upstash). Material access events are logged where supported by the provider.

3.1 School-authorized onboarding for under-13 athletes

RepRoom supports onboarding of athletes under 13 through a school-authorized path that operates under the school authorization exception of the Children's Online Privacy Protection Act (COPPA). The technical and authorization controls for this path are:

• Institution-level authorization gate. Under-13 onboarding is unavailable until the institution's Primary Administrator has executed RepRoom's Data Privacy Agreement (DPA) through the institution settings interface. The signing event is recorded with the signer's user identifier, full name, title, IP address, timestamp, and DPA version, and is enforced as a precondition at the service layer for any minor-onboarding action.
• Team-level affirmative opt-in. Within an institution that has executed the DPA, minor onboarding must be explicitly enabled by a coach on a per-team basis. The default state is off.
• Claim-code flow. Under-13 accounts are created through coach-generated claim codes — not through the standard signup flow. No email address, date of birth, phone number, photograph, or precise geolocation is collected from the under-13 user during account creation. The athlete (or their parent or guardian) uses the claim code to set a username and password.
• Restricted profile fields. Optional profile fields available to other users (height, weight, birthday, bio) are disabled at the application layer for under-13 accounts.
• No outbound messaging. RepRoom does not send transactional, account, or marketing email to under-13 athletes; no email address is on file for those accounts. Password resets are handled through the coach.
• Audit logging. DPA execution events, minor-onboarding toggle changes, claim-code generation events, and claim events are recorded in the audit log for at least 90 days.

The user-facing terms and rights associated with this path are described in our Privacy Policy (Section 2) and Terms of Service (Section 1).

4. Application security

Input validation. Inbound API payloads are validated by hand-written validators that enforce shape, type, and constraints (length limits, format requirements, role enums) before any database operation. Validation failures return 400 responses without leaking internal state.

Rate limiting. Sensitive endpoints are rate-limited using a shared Upstash Redis store with sliding-window enforcement, so limits are enforced consistently across serverless instances:

• Signup: 5 requests per 60 seconds per IP
• Login failures: 5 per 5 minutes per email
• Messaging: 60 messages per minute per user
• Data export: 5 requests per hour per user
• Claim-code redemption: 5 attempts per 15 minutes per IP

When the Upstash store is unavailable, the limiter logs a warning and falls back to a no-op so the application remains accessible.

Output encoding. User-generated content is rendered through React's default HTML escaping. We treat all user input as untrusted at render time.

CSRF protection. Authenticated mutating requests rely on session cookies set with SameSite=Lax and same-origin enforcement. Stripe webhook calls are verified using Stripe's signature verification before processing.

Dependencies. All dependencies are managed through npm with lockfile pinning. Dependency advisories are monitored via GitHub Dependabot. Security updates to direct dependencies are applied promptly.

Secrets management. All secrets (database connection strings, API keys, signing secrets) are stored in Vercel's encrypted environment variable system, scoped per environment (Production, Preview, Development). No secrets are committed to source control. The repository's .gitignore excludes .env files; only .env.example (with no secret values) is committed.

Webhooks. Inbound webhooks from Stripe are verified using Stripe's published signature scheme before any side effect is taken. Webhook handlers are idempotent.

5. Data handling

Data minimization. RepRoom collects the information needed to operate the Service. Athletic profile fields beyond the basics (bio, height, weight, jersey number, position) are optional. Under-13 athlete accounts are subject to additional minimization rules described in Section 3.1. We do not collect data we do not need.

Visibility model. Data access within the application is scoped by team membership and role. Athletes see content scoped to their groups, tags, and positions. Coaches see content for teams they coach. Institution administrators access content across all teams in their institution; this is disclosed in our Privacy Policy and at signup.

Soft deletion is applied to most user-facing entities — accounts, athletic profiles, teams, team members, group and tag memberships, messages, message threads, events, announcements, and others — allowing recovery and audit visibility before any hard deletion occurs. Read paths are filtered through middleware that excludes soft-deleted rows from normal queries.

Audit logging. RepRoom logs sensitive actions — including login success and failure, account deletion, data export, institution administrator access to organization-wide content, DPA execution, minor-onboarding toggle changes, claim-code generation, and claim-code redemption — to an audit log retained for at least 90 days. Role changes will be added to the audit log when institution role management is implemented.

Data export. A self-service data export endpoint is available at GET /api/teams/[teamId]/export, accessible to head coaches and institution administrators. The export returns a complete JSON snapshot of team data and is rate-limited to 5 requests per hour per user.

Backups. Encrypted daily backups of our database are retained for up to 7 days for disaster recovery, in line with our database provider's backup retention.

Retention. Data retention timelines are described in detail in our Privacy Policy.

6. Hosting, regions, and data residency

All RepRoom production data is hosted in the United States. We do not currently offer non-US data residency. Customers requiring non-US data residency should contact us before signing a contract.

7. Subprocessors

A current list of subprocessors — including the categories of data each one processes, hosting regions, and certifications — is published at reproom.dev/subprocessors. Institutional customers may request advance notification of subprocessor changes by contacting privacy@reproom.dev.

8. Incident response

If we become aware of a security incident affecting personal information, we will:

1. Investigate and contain the incident
2. Notify affected institutional customers within 72 hours of confirming a reportable incident, using the incident-notification contact information on file
3. Notify affected individual users on a timeline consistent with applicable law and the relevant institutional agreement. For incidents involving the personal information of under-13 athletes, we will notify the athlete's institution within 72 hours and rely on the institution to communicate with affected parents and guardians, except where applicable law requires direct notification.
4. Provide a summary of root cause, scope, and remediation
5. Cooperate with affected institutions' incident-response, regulatory-reporting, and notification obligations

We maintain documented incident-notification contact information for each institutional customer and review it periodically.

9. Vulnerability reporting

We welcome reports of potential security vulnerabilities from the security research community. To report a vulnerability, contact security@reproom.dev with as much detail as you can reasonably provide.

Our commitments to good-faith researchers.

• We will acknowledge receipt of your report within 2 business days
• We will provide an initial assessment within 7 business days
• We will work in good faith on remediation and keep you informed of progress
• We will not pursue legal action against researchers who report vulnerabilities responsibly under this policy, including the Computer Fraud and Abuse Act and similar state laws
• Where appropriate and with your permission, we will publicly credit you for the discovery after remediation

What we ask of researchers.

• Give us reasonable time to remediate before public disclosure (we suggest 90 days)
• Do not access, modify, or download other users' data beyond the minimum necessary to demonstrate the vulnerability
• Do not degrade or disrupt the Service (no denial-of-service testing, no destructive testing)
• Do not attempt to extort or threaten RepRoom
• Comply with applicable law

This is a vulnerability disclosure policy, not a paid bug bounty program. We do not currently offer monetary rewards. We may revisit this in the future.

10. Compliance posture

FERPA. When RepRoom is used by a school under a Data Privacy Agreement, we operate as a "school official" with a legitimate educational interest as defined in the institution's agreement, and we follow the institution's instructions regarding student records.

COPPA. RepRoom's standard signup flow is restricted to users 13 and older and does not knowingly collect personal information from children under 13. RepRoom additionally supports a school-authorized onboarding path for under-13 athletes that operates under the COPPA school authorization exception, conditioned on the institution's executed Data Privacy Agreement and a coach's affirmative per-team opt-in. The technical controls for this path are described in Section 3.1, and the user-facing terms are described in our Privacy Policy and Terms of Service.

State student-privacy laws. We are prepared to execute the Student Data Privacy Consortium National Data Privacy Agreement (SDPC NDPA) or institution-specific equivalents. We comply with applicable state student-privacy laws, including the Kansas Student Data Privacy Act, where they apply to our institutional customers.

State consumer-privacy laws. We respect rights granted to residents of states with comprehensive privacy laws — including California (CCPA/CPRA), Virginia, Colorado, Connecticut, Utah, Texas, and others — as described in our Privacy Policy.

HIPAA. RepRoom is not a HIPAA-covered service. Do not store protected health information (PHI) in RepRoom. Athletic data such as height, weight, jersey number, and performance metrics are not PHI in this context, but injury, diagnosis, and medical treatment information should be kept in a HIPAA-appropriate system.

SOC 2 / ISO 27001. RepRoom is not currently certified under SOC 2 or ISO 27001. Formal certification is a long-term roadmap item and will be reconsidered as the company scales. Our infrastructure providers (Supabase, Vercel, Upstash, Resend, Stripe) are independently SOC 2 certified.

11. Insurance

Cyber liability and errors & omissions insurance is not currently in place. We plan to obtain coverage as the business scales and before signing contracts with institutional customers that require it. Prospective customers requiring proof of insurance should contact us at legal@reproom.dev to discuss timing and coverage requirements.

12. Contact

• Security issues: security@reproom.dev
• Privacy and DPA requests: privacy@reproom.dev
• General legal: legal@reproom.dev