Security

Security at Learning Whistle

Last updated: May 2026

This page describes the technical and organisational controls we use to protect your data. We publish this in the spirit of transparency — not as marketing copy, but as an honest account of what we do and where our gaps are.

5-page technical whitepaper — suitable for compliance reviews, enterprise procurement, and school IT departments.

Reporting a Vulnerability

If you discover a security issue, please report it privately before disclosing publicly. Email learn@learningwhistle.com with the subject line [SECURITY] followed by a brief description.

We commit to:

  • Acknowledging your report within 48 hours
  • Providing a remediation timeline within 7 days
  • Crediting you in our changelog (unless you prefer anonymity)
  • Not taking legal action against good-faith researchers

A machine-readable disclosure policy is available at /.well-known/security.txt.

Platform Architecture

Learning Whistle runs entirely on Google Cloud Platform. All compute is serverless — there are no long-lived servers to patch. The stack:

  • Hosting: Google Cloud Run — managed containers, automatic TLS, no persistent servers
  • Authentication: Firebase Auth with Google OAuth only — no passwords
  • Database: Cloud Firestore — server-enforced security rules per user
  • Secrets: Google Secret Manager — credentials mounted at runtime, never in code
  • AI: Google Gemini — server-side only, your data is not sent to third-party AI services
  • Payments: Stripe — card data never reaches our servers

Authentication & Session Management

  • Google OAuth only. There are no passwords to breach or reset flows to abuse.
  • Session cookies are HttpOnly, Secure, and SameSite=Strict — unreadable by JavaScript.
  • Every protected route performs a live revocation check against Firebase — not just JWT signature validation.
  • Account suspensions propagate within 60 seconds without requiring a forced logout.
  • COPPA: Users who report being under 13 have their Firebase token revoked server-side immediately. No data is written before this gate passes.

Authorization — Least Privilege at Every Layer

Firestore Security Rules

  • Users can only read and write their own documents
  • Users cannot self-promote to admin or grant themselves Gold Tickets
  • Admin audit logs and health collections block all client access — server-only
  • Audit trail collections are append-only — no updates or deletes

GCP Service Accounts

The Cloud Run service runs as a dedicated cloud-run-app@ service account with only the permissions it needs: Secret Manager read access, Vertex Search viewer, Vertex AI user, and Cloud Storage write access scoped to the assets bucket only. The default compute service account has no project-level roles.

Keyless CI/CD Authentication

The deploy pipeline authenticates to GCP using Workload Identity Federation — no static service account keys exist anywhere in the repository or CI secrets. The identity pool is scoped to the exact GitHub repository.

Data Protection

  • At rest: Firestore and Cloud Storage encrypted with AES-256 (Google-managed keys)
  • In transit: TLS enforced end-to-end; HSTS with 1-year max-age and preload flag
  • Payments: Card data handled entirely by Stripe — never stored by us
  • Secrets: All server credentials in Google Secret Manager — never in source code or image layers
  • Google profile photo: Stored as a URL only — never displayed on any public surface

Application Security Controls

  • Rate limiting: AI generation and write-path routes are rate-limited per authenticated UID or anonymous IP. Exceeding limits returns HTTP 429.
  • Input validation: All API inputs validated with Zod schemas. Invalid payloads return HTTP 400 with no server detail exposed.
  • Prompt injection defence: User-supplied topics are sanitised before reaching the AI model. Injection patterns, HTML, and instruction overrides are stripped. Topics capped at 200 characters.
  • Content Security Policy: All responses include a CSP header — default-src 'self', object-src 'none', base-uri 'self'.
  • CVE-2025-29927: Next.js middleware bypass is explicitly blocked — returns HTTP 403.

Supply Chain Security

  • Dependabot monitors all npm and GitHub Actions dependencies continuously
  • Hourly watcher sends email within 2 hours of any new critical or high CVE
  • Semgrep SAST runs on every push using OWASP Top 10 and secrets rulesets
  • npm ci used in all pipelines — exact lockfile installs, no silent upgrades
  • Every deploy runs npm audit --audit-level=high and blocks on findings

Incident Response

  • Affected users notified within 72 hours of confirming a breach (GDPR Article 33 standard)
  • Public post-mortem published within 30 days of resolution
  • Payment data is Stripe-scoped — their breach notification process applies to card data

Known Gaps

We believe transparency includes honesty about what we have not yet done:

  • Nonce-based CSP (to remove unsafe-inline) — planned Q3 2026
  • Per-secret IAM bindings in Secret Manager — planned Q3 2026
  • DKIM / SPF / DMARC audit for learningwhistle.com — planned Q3 2026
  • Firestore backup restoration runbook — planned Q3 2026

Questions? Email learn@learningwhistle.com — we respond to all security enquiries within 48 hours.