Status: Pre-production security assessment Assessment date: 2026-07-12 Scope: This repository's React application, Firebase configuration/functions/rules, Stripe integration, Strava integration, CI/CD, operational data, and documented deployment model

This is both the repository security policy and the current engineering risk register. It is not a penetration-test report, legal opinion, PCI attestation, privacy certification, or guarantee that deployed cloud settings match the repository. External Firebase, GCP, Stripe, GitHub, DNS, Sentry, and email-provider configuration must be reviewed separately.

The public informational website can continue operating with normal care. Live race or merchandise payments should remain disabled until every P0 launch blocker below is closed and verified in a staging dress rehearsal. The existing payment implementation is a useful prototype, but several correctness defects could mark unpaid transactions paid, lose payment callbacks, oversell race capacity, fail to reconcile late-payment links, or allow overly broad administrative access.

Do not disclose a suspected vulnerability, secret, customer record, payment reference, or exploit in a public GitHub issue. Until MPRC publishes a dedicated security address:

1. Use the private contact channel listed on the live MPRC contact page.
2. State that the message is a security report and request a secure reply channel.
3. Include the affected URL/component, impact, reproduction with synthetic data, and any suggested mitigation.
4. Do not access, change, download, or retain data beyond what is necessary to demonstrate the issue.

An implementation issue must establish security@runmprc.com or another monitored private address, named primary/backup responders, an acknowledgement target, and a disclosure policy before commerce launch.

• P0 — launch blocker: credible risk of incorrect money state, privilege compromise, secret/PII exposure, oversell, or inability to recover safely. No live payments.
• P1 — high: material abuse, privacy, availability, or operational-control weakness. Complete before broad launch or explicitly accept with a time-bounded compensating control.
• P2 — medium: defense-in-depth, maintainability, or bounded operational risk. Schedule soon after the secure pilot.
• P3 — improvement: useful hardening with lower immediate impact.

Closing an item requires code/configuration, automated or documented tests, deployed-environment evidence, monitoring, and an owner—not only a code diff.

The findings below describe the repository at the start of the 2026-07-12 assessment. The IDs use the RISK-* namespace so they cannot be confused with the independently publishable issue IDs in GITHUB_ISSUES.md. A working-tree fix lowers exposure only after review, merge, deployment, external configuration, and evidence; the remediation ledger after the tables records that distinction.

These entries are implementation evidence, not a production risk-acceptance decision:

• Stripe secret keys, webhook secrets, refunds, payout/account settings, and financial reports.
• Firebase/GCP service credentials, deployment authority, Auth role claims, and App Check configuration.
• Runner identity, date of birth, phone, emergency contact, waiver evidence, and attendance.
• Buyer identity, shipping address, order history, and tracking information.
• Member profiles and Strava access/refresh tokens and activity data.
• Race capacity, merchandise inventory, discounts, email reputation, and cloud budget.
• GitHub repository, workflows, DNS/custom domain, production artifacts, and audit history.

• Opportunistic unauthenticated bots testing public functions and credential stuffing.
• A customer manipulating price, member tier, custom fields, checkout retries, refunds, or inventory races.
• A compromised member or admin account.
• An insider with more access than their job needs.
• A leaked CI/cloud/Stripe/OAuth secret.
• A compromised dependency, GitHub Action, browser extension, or operator device.
• Accidental operator/developer action against production.
• Webhook duplication, delay, reordering, provider outage, or partial network failure without malicious intent.

1. Submit a member tier while unauthenticated or using an unverified known member email.
2. Race two last-seat/last-SKU requests.
3. Reuse a client request after a timeout to create multiple Sessions or refunds.
4. Pay a Session after the operator cancels the local record.
5. Replay or reorder a valid Stripe event.
6. Apply an unmodeled Stripe promotion and obtain goods while local records show another total.
7. Steal an admin token and read OAuth secrets or directly rewrite financial records.
8. Script public callables without App Check to create Stripe objects, Firestore writes, or cloud cost.
9. Inject markup/formulas/oversized data through names, notes, custom fields, email, or exports.
10. Cause local development to call production Functions.

• Firebase Auth verifies identity; email ownership must be verified before member/admin grants based on email.
• Privileged accounts require MFA and a documented account-recovery process.
• Sensitive operations require recent authentication where supported.
• Auth error messages do not reveal whether an account exists beyond Firebase's approved behavior.
• Role changes force token refresh/revocation and emit a durable audit event.

• Server code and Firestore rules check signed token capabilities; the UI is never the enforcement point.
• Separate catalog/content editing from financial state, identity administration, exports, and secrets.
• No client—including browser admins—can write webhook inbox, payment state, refund IDs, Stripe IDs, audit events, rate limits, or OAuth secrets.
• Server service accounts use IAM least privilege because Admin SDK bypasses Firestore rules.

• Use reCAPTCHA Enterprise for web App Check and observe metrics before enforcing.
• Set runtime enforceAppCheck: true on every sensitive callable instead of a custom fail-open environment test.
• Consider limited-use/replay-protected tokens only for the most abuse-sensitive callable after measuring latency and SDK support.
• Keep rate limits as defense in depth; App Check is not user authorization and does not stop all valid-browser abuse.
• Apply cloud budgets/alerts and Stripe rate/error alerts so cost abuse is visible.

• Centralize strict request schemas with maximum object depth, field count, string length, array length, total bytes, integer ranges, enum values, and URL allowlists.
• Normalize email consistently; do not over-normalize names or assume ASCII.
• Validate event custom fields against the stored schema.
• Escape HTML email content, neutralize spreadsheet formulas, and let React escape browser rendering.
• Avoid rendering arbitrary HTML from Firestore. If business requirements demand it, sanitize with a maintained allowlist library and a restrictive CSP.
• Return generic errors to unauthenticated clients; log structured error codes without secrets/PII.

• Store server secrets in Google Secret Manager and bind each only to functions that need it.
• Never use REACT_APP_* for a secret; CRA embeds those values in public JavaScript.
• Keep local overrides ignored (.secret.local, .env.local) and commit only name/format examples.
• Rotate Stripe and webhook secrets independently, with an overlap plan where the provider supports it.
• Inventory owners, creation dates, consumers, last rotation, and emergency revocation steps.
• Remove long-lived GitHub service-account JSON in favor of workload identity/OIDC when feasible.

The binding design is in STRIPE_COMMERCE_DESIGN.md. Its mandatory controls are server price authority, persistence-first checkout, Stripe and application idempotency, atomic capacity/inventory, verified async-aware webhooks, allowed state transitions, idempotent refunds, and reconciliation.

Proposed retention values must be approved by counsel, finance, insurance, and operations. A reasonable minimization starting point for discussion is:

• Unpaid/expired checkout PII: delete or anonymize within 30 days after final reconciliation.
• Emergency contact and DOB: delete after the event plus a short operational/incident window unless insurance/counsel requires longer.
• Shipping address: remove from routine operator access after fulfillment/return window; retain only fields legally required for accounting/tax.
• OAuth tokens: delete immediately on disconnect/account deletion; rotate on suspected exposure.
• Rate-limit identifiers: expire shortly after the enforcement window and store HMACs, not raw values.
• Webhook inbox: retain non-PII identifiers long enough for reconciliation/audit, then expire under policy.
• Payment/accounting and waiver evidence: retain only for the approved legal/accounting/insurance period, separately from unnecessary operational PII.

Backups and exports must honor eventual deletion/anonymization schedules and have documented access.

• Correlation/request ID, function name, environment, code version, local business ID, Stripe Event/type/object ID, state transition, latency, and sanitized error code.
• Authentication UID for privileged actions, capability used, target resource, reason, and result.
• Reconciliation counts and anonymous mismatch categories.

• Stripe or OAuth secrets, bearer tokens, full webhook payloads, Checkout URLs, password/reset data, raw ID tokens, session cookies, full addresses, DOB, emergency contacts, or arbitrary request bodies.
• Full customer email/IP in rate-limit and security logs; use a keyed pseudonymous identifier where correlation is needed.

• Invalid webhook signature spikes.
• Event inbox failed/quarantined/old items.
• Paid Stripe Session with no local record or amount/currency mismatch.
• Local paid record not verified in Stripe.
• Refund/dispute creation and failed refund reconciliation.
• Capacity/inventory counter drift or negative availability.
• Elevated callable rejects, App Check failures, Auth abuse, cloud budget anomalies, deploy failures, secret access, and role grants.

• Protect main and production environments with pull-request review and required passing checks.
• CI must run non-mutating lint, frontend tests, Functions tests, Firestore Rules emulator tests, production build, secret scan, and dependency scan.
• Do not use lint:fix as the CI lint command or mask it with || true.
• Pin GitHub Actions to reviewed major versions or immutable SHAs according to the project's maintenance capacity.
• Dependabot/Renovate updates are small, reviewed, and tested; do not blindly npm audit fix --force.
• Generate an SBOM/release dependency inventory for live commerce builds.
• Restrict production deployment to protected environment approval; use short-lived federated cloud credentials.
• Deploy backward-compatible backend/rules/indexes before dependent frontend changes.
• Record release commit, migration, function version, Stripe webhook/API version, test evidence, and rollback point.

• SEV-1: Stripe/GCP/GitHub secret exposure; unauthorized refund/payout/role change; confirmed PII exfiltration; active payment misclassification at scale.
• SEV-2: Webhook backlog or reconciliation mismatch affecting customers; capacity/inventory oversell; admin account compromise without confirmed data access.
• SEV-3: Bounded availability failure, attempted abuse blocked by controls, or non-sensitive data issue.

1. Name the incident commander and scribe; preserve timestamps and evidence.
2. Stop harm: disable new checkout, revoke/rotate affected credentials, revoke sessions/roles, or isolate the deployment.
3. Do not destroy logs or silently rewrite financial records.
4. Compare Stripe and Firestore using the reconciliation runbook.
5. Notify Stripe/Firebase/GitHub or other vendors through their security/support channels when relevant.
6. Determine legal, insurance, customer, and regulatory notification with qualified advisers.
7. Restore through an audited repair, test it, monitor, and document every changed record.
8. Complete a blameless post-incident review with owners and deadlines.

Specific playbooks live in OPERATIONS_RUNBOOK.md.

• Passing CI link and commit SHA.
• Dependency scan with zero unaccepted critical/high runtime findings.
• Firestore Rules test report proving browser admins cannot read secrets or directly mutate financial records.
• App Check metrics and enforcement proof for each callable.
• Stripe test-mode event delivery showing valid, duplicate, invalid, async, expired, refund, and dispute paths.
• Concurrency test showing no capacity/SKU oversell.
• Reconciliation report with zero unexplained mismatches.
• Secret/IAM/role inventory reviewed by two owners.
• Approved policies/waiver versions and retention matrix.
• Backup restore exercise and checkout-disable drill.
• Limited live pilot report and finance confirmation that Stripe payouts/totals match local records.

• Stripe webhook best practices
• Stripe Checkout fulfillment and delayed methods
• Stripe idempotent requests
• Firebase App Check enforcement
• Firebase Secret Manager and environment configuration
• Firestore IAM and least privilege
• Firestore Security Rules conditions

Re-check first-party documentation during implementation because provider behavior and recommended controls change.