Security & Privacy

Last updated May 22, 2026 · Questions: info@cubbyed.com

We treat your child's data the way we'd want our own treated. This page is an honest, up-to-date account of what Cubbyed does — and doesn't yet do — to keep that promise. When you read about a learning platform getting hacked, the cause is almost always the same: one big database with overly broad access, an admin password floating in someone's email, no real per-user rules. Cubbyed was built without any of that. The list below is the architecture, not the marketing.

Access control

• Default-deny database rules. Every Firestore collection has an explicit, server-enforced allow rule keyed to identity — owner-only reads of user profiles, teacher-only writes of class study decks, author-only deletes of annotations, no client writes at all for AI-generated content. Adding a new collection requires adding an explicit rule; the safest failure mode.
• No "test-mode" wildcard rules. A previous version of the rules allowed any signed-in user to read or write any document. That hole is closed; rules are versioned and reviewed.
• Every Cloud Function requires an authenticated caller. Receipt validation, subscription checkout, daily-content approval — every callable starts by rejecting unauthenticated requests.
• Administrators use 2FA. Every admin of the Google Cloud project has hardware-key / TOTP second-factor enforced.

Encryption

• In transit: TLS 1.3 on every request, enforced by HSTS with a one-year max-age and preload directive — your browser refuses to load Cubbyed over plain HTTP.
• At rest: all Firestore documents are encrypted at rest using Google-managed keys. Disk-level encryption on Cloud Functions storage.
• Secrets: API keys, webhook secrets, and the agent's Anthropic key live in Google Secret Manager, not in the codebase. They're injected into functions at runtime.

Authentication

• Sign in with Apple on iOS — Apple's privacy-preserving auth (private relay emails supported).
• Google Sign-In on web (works on school Chromebooks).
• Email + password via Firebase Auth. Passwords are never stored by Cubbyed — only by Firebase, which uses scrypt with project-level salt and pepper.
• Account deletion in-app under Settings → Account → Delete account. Profile and tokens are revoked immediately; queued backups purge on the next 30-day cycle.

Payments

• Stripe handles all card data on web and Android. Cubbyed servers never see, log, or store a card number, CVC, or expiration.
• Apple In-App Purchase handles iOS subscriptions. Receipts are verified server-side against Apple's verification endpoint with a sandbox fallback.
• Stripe webhooks are signature-verified before any database write, using a per-project webhook secret.

Web hardening

• Content-Security-Policy with full enforcement on the marketing site and report-only on the app while we baseline Flutter web's runtime needs.
• HSTS with preload.
• X-Frame-Options: DENY plus frame-ancestors 'none' — Cubbyed cannot be embedded in another site's iframe, eliminating clickjacking.
• X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy with camera, microphone, and FLoC turned off.
• Cross-Origin-Opener-Policy to prevent cross-tab attacks.

Privacy by design

• No advertising. No behavioral tracking. No data brokers. We don't sell student data — and structurally couldn't, because we don't collect the kind of profile ad networks buy.
• No student-to-student messaging. Annotations are scoped to a class and visible only to that class's teacher and the annotation's author. Bullying has no vector.
• No third-party analytics SDKs with cross-site tracking in the child-facing surfaces.
• COPPA-compliant consent flows; we collect the minimum needed to operate.
• FERPA-aligned design: schools remain the data controller for the records they upload; we operate strictly as a service provider.

Building for resilience

• All persistence is in Firebase / Firestore, which auto-replicates across multiple zones — there is no single-machine database that can be hacked in a smash-and-grab.
• Cloud Functions are stateless and per-request authenticated.
• Continuous monitoring through Google Cloud's logs, with separate access controls on the project itself.

What we don't do (yet)

We'd rather list this honestly than imply certifications we don't have.

• No SOC 2 audit yet. Cubbyed is small and early. We design to those standards (least privilege, secrets management, encryption, audit trails) and intend to pursue formal certification once the product warrants the audit cost.
• No bug-bounty program yet. Disclosures via the email above are acknowledged and handled, but we cannot yet offer cash bounties.
• No third-party penetration test on record yet. Planned; we'll publish the letter when complete.

Update history

• 2026-05-22: Initial public security policy. Default-deny Firestore rules deployed. Web security headers (HSTS, CSP, COOP, Permissions-Policy) added on both the marketing site and the app.

Cubbyed is built by Ryan Breitenbach. Questions, concerns, or disclosures: info@cubbyed.com.