Found a security
issue?

We take the security of our users' data seriously. If you've discovered a vulnerability in Family Day2Day, we want to hear about it. This page describes how to report it and what to expect when you do.

What to include

• A clear description of the vulnerability
• Steps to reproduce — ideally with a short proof-of-concept
• Impact: what data or actions does it expose?
• Any preferred attribution / handle you'd like in our acknowledgements

What's in scope

• www.familyday2day.com and all subdomains we operate
• The Family Day2Day iOS app (bundle ID com.familyday2day.app)
• The Family Day2Day Android app (package com.familyday2day.app)
• The HTTP API at www.familyday2day.com/api
• Email delivery, authentication, push notification, and data-sync infrastructure that processes our users' data

How we protect your data

• Database isolation: every per-family table enforces Postgres Row-Level Security (RLS) at the database layer; a query that forgets the tenant filter returns zero rows rather than leaking another family's data.
• Bring-Your-Own AI keys encrypted at rest: when a Family Admin pastes their own Anthropic API key in Settings → Your AI key, it's encrypted with AES-256-GCM using a server-side master key. We never log the value, never ship it to other systems, and only display the last 4 characters in the UI.
• Sessions: JWT-based with HttpOnly + Secure cookies on web, SecureStore on native. Force-logout invalidates every active session for a family in a single DB write.
• Per-tenant resource caps: statement-level timeout on every DB query, per-family daily write rate-limit, blob-size watchdog. A runaway client cannot DOS the database for other families.
• Backups: daily snapshots per family with 14-day rotation. Neon also provides point-in-time recovery on its own retention schedule.

What's out of scope

• Third-party services we use (Anthropic, Vercel, Neon, Resend, Expo, Google, ip-api.com) — please report to the vendor directly
• Denial-of-service attacks (rate-limit-bypass reports are welcome; volumetric DoS is not)
• Social engineering of our staff or users
• Physical attacks on our infrastructure
• Self-XSS that requires the victim to paste content into a console
• Missing security headers / best-practice findings with no demonstrable exploit (we welcome these, but they're informational, not vulnerabilities)

Safe harbor

If you make a good-faith effort to comply with this policy during your security research, we will:

• Not pursue or support any legal action against you
• Work with you to understand and resolve the issue quickly
• Recognize your contribution publicly (with your permission) once the issue is fixed

To stay in good faith, please:

• Only access data that is yours, or explicitly created for testing
• Do not exfiltrate, modify, or destroy data that doesn't belong to you
• Do not attempt to access other users' family data, chat content, or personal information
• Give us a reasonable time to remediate before any public disclosure (we target 90 days as a default)
• Avoid degrading the service for other users (no flooding, no destructive automated scanning)

Bounty

We don't currently run a formal bug bounty program. For high-impact findings we may offer a thank-you payment or App Store credit at our discretion. The biggest reward is our public thanks and the satisfaction of helping families stay safer.

Acknowledgements

None yet. Be the first?

Last updated: 2026-05-25 · See also security.txt