Security

Vulnerability Disclosure.

Effective April 19, 2026 · Version 2026-04-19

If you think you've found a security issue in Build Understanding, please tell us. We'll respond fast and work with you in good faith.

Email security@buildunderstanding.app with a description of the issue and reproduction steps. Don't run automated scans against the live site, don't access other users' data, and please give us a reasonable window to fix the issue before publishing.

01How to report

Send an email to security@buildunderstanding.app with:

  • A clear description of the vulnerability and its impact.
  • Step-by-step reproduction or a proof-of-concept.
  • The affected URL, route, or component.
  • (Optional) your name or handle for credit in the fix changelog.

We acknowledge reports within 3 business days and aim to ship a fix for High/Critical severity issues within 14 days. Lower-severity items go on the regular hardening roadmap.

02Scope

In scope: the production app at buildunderstanding.app, all *.buildunderstanding.app subdomains, the public API under /api/*, and the iOS / Android wrappers if published.

Out of scope: third-party services we use (Stripe, Supabase, Anthropic, Resend, Vercel) — please report those directly to the relevant vendor. Social engineering of staff, physical attacks, and findings only reproducible in unsupported browsers are also out of scope.

03Safe-harbor commitments

If you make a good-faith effort to comply with this policy during your research, we will not pursue legal action against you. We ask that you:

  • Don't access, modify, or delete data that isn't yours.
  • Don't degrade service for real users (no DoS, no automated bulk scans).
  • Don't publish the issue until we've had a chance to fix it (we'll coordinate disclosure).
  • Test on a dedicated test account, not on student or family accounts.

04What is already covered

Before reporting common items, note these defenses already shipped: signed-JWT sessions with revocation (jti + bulk invalidation), strong CSP without unsafe-eval, Stripe webhook signature verification + idempotency, row-level security on every user-data table, DOMPurify on all model-generated SVG, KaTeX with trust=false, fail-closed rate limiting on auth endpoints, and a safe math-expression parser in place ofnew Function(). If your finding builds on one of these defenses being bypassed, please call that out explicitly.

05security.txt

This policy is also published machine-readably at /.well-known/security.txt per RFC 9116.