How Core approaches account security, role-based access, private student data, payments, account exports and deletion requests.
Access follows the user's role
Community admins manage their school, teachers work with students in the classes they teach, and families see their own students. Private application routes verify signed-in users before returning protected data.
Database rules are part of the boundary
Firestore and file-storage rules restrict access by signed-in identity, community membership and role. The public marketing site never publishes a school's private roster, records or community documents for search engines.
Authentication and abuse controls
Core uses Firebase Authentication, server-side token verification, request rate limits and bot-detection controls on sensitive account workflows. Password reset and recovery requests are limited to reduce automated abuse.
Card details stay with Stripe
Card payments are processed by Stripe. Core records transaction status and references needed for the school ledger, but does not receive or store a user's full card number.
Users have data controls
Signed-in users can request an export of their account data and submit an account deletion request from the More section. Some school records may need to be retained by the school or as required by law.
Security is maintained, not declared finished
Core uses validation, security headers and automated checks as part of development. No public page claims that software can eliminate every risk, and schools should evaluate Core against their own legal and policy requirements.