Effective date: September 12, 2026. This page summarizes technical and operational controls in the live application. It is not a SOC 2, HIPAA, or FERPA certification.
Implemented today
- HTTPS in production with security response headers (HSTS, CSP, clickjacking and cross-origin protections).
- Password hashing with bcrypt; temporary passwords are not stored in plaintext in the database.
- Login throttling / lockout after repeated failures; failed attempts can be audit-logged.
- Role-based portals (admin, cashier, parent, teacher, staff, student) with server checks on sensitive APIs.
- Parent/family actions scoped to linked students where applicable (deposits, photos, dietary forms).
- Cashier kiosk PIN verified on the server (timing-safe); incorrect attempts are rate-limited; short-lived station token required for scan lookups after unlock.
- Stripe Checkout for cards — Fuel The Dons never stores PAN/CVV; webhooks are signature-verified.
- Student photo moderation before badge/kiosk use of parent-uploaded photos.
- Administrative audit logging for user management, funds changes, allergy approvals, and related events.
- Security alert emails (when email is configured) for suspicious login patterns, admin password resets, and Stripe disputes.
- Secrets (database URL, Stripe secret, Resend key, kiosk PIN, API keys) kept in server environment variables.
- Database hosted with platform encryption at rest (Supabase/Postgres) plus Row Level Security on public tables.
Data handling highlights
- Student and family PII APIs require authentication; parents receive linked-student scoped data.
- Financial archive (older than ~6 months) is limited to admin/cashier sessions.
- Teacher/staff roster payloads redact parent contact details on shared student list endpoints.
- Offline kiosk mode may cache student name, photo, balance, and allergies on the device IndexedDB for scan continuity.
Honest limitations
- Portal sessions use browser session storage plus a session user header rather than HttpOnly cookie sessions.
- Rate limits are defense-in-depth and strongest when combined with hosting/WAF limits.
- We rely on platform database encryption at rest; we do not currently encrypt individual medical-note columns inside the app.
- No system can guarantee that breaches will never occur; we reduce risk and improve detection.
Recommended next steps (not claimed as live)
- Signed HttpOnly sessions or a managed identity provider.
- Formal retention/deletion and parent data-export workflows.
- Independent penetration testing and written subprocessors agreements for school counsel.
Related documents
Families: Privacy Policy · Terms of Use. School counsel also receives a detailed summary in the repository (docs/LEGAL-DATA-PROTECTION.md) and in Admin → Legal / Data protection.