Security Statement

Infrastructure

• Hosted on a modern edge platform with automatic TLS on all endpoints.
• Managed Postgres database with encryption at rest; uploaded course materials and chat attachments are stored in access-controlled object storage.
• Daily automated backups retained for 7 days; longer for institutional plans on request.
• Separate preview and production environments; secrets are injected at runtime and never committed to source.

Accounts and access control

• Instructors, teaching assistants, administrators, and students all authenticate through our managed authentication service. Passwords are hashed with industry-standard algorithms and never stored in plaintext.
• Optional Google sign-in for accounts that prefer SSO over passwords.
• Row-level security policies in the database enforce that a user can read and write only the sections, questions, chat, rooms, and records they are entitled to — enforcement happens at the data layer, not in the interface.
• Roles are stored separately from profiles and checked server-side, so a client cannot elevate its own privileges.
• Student Class Chat, Study Rooms, and Direct Messages are not readable by course staff or institution administrators; this is enforced by access policies, not by hiding UI.
• Privileged server operations require both authentication and an explicit role check.

Class integrity

• Attendance check-in codes are derived from a per-session secret and rotate every 20 seconds, with sessions closing automatically — codes cannot be reused or shared ahead of time.
• Attendance records and activity responses are written only through server functions that verify enrollment, live session state, and one-response-per-question rules.
• Per-class rate limits protect Live Questions and chat from floods.

Payments

All payment processing — for institution seat purchases and for student self-pay subscriptions — is handled by Stripe. HUSH never sees or stores full card numbers; card details go directly from the checkout page to Stripe. We store only a Stripe customer ID and the last four digits. Billing webhooks are signature-verified before they are processed.

AI processing

• AI requests route through a server-side gateway; model credentials are never exposed to the browser.
• The Course Assistant is scoped to a single class's materials, so one course's content cannot be retrieved from another.
• We contractually prohibit providers from training on our data; providers may retain inputs briefly for abuse monitoring.
• See the Privacy Policy for exactly which content each AI feature sends.

Notifications

Web push messages are encrypted end-to-end to the device subscription using the standard Web Push encryption scheme, and device tokens are removed when a subscription expires or a user disables notifications.

Application security

• Server-side input validation on all state-changing endpoints.
• Server-side authorization checks — we do not rely on hiding UI elements.
• Content Security Policy and standard security headers on all responses.
• Uploads are type- and size-checked and served from an isolated storage origin.
• Dependencies scanned regularly; critical vulnerabilities patched within 7 days.

Monitoring and response

• Server errors and unusual authentication activity are logged and reviewed.
• We investigate credible reports of security issues within one business day.
• Where a breach affects personal data, we notify affected institutions and users as required by law.

Reporting a vulnerability

Please report it through our contact form with details and reproduction steps. We do not currently offer a paid bounty, but we credit reporters on request. Please give us a reasonable window to remediate before public disclosure.

Institutional agreements

For institutions that adopt a HUSH institutional plan, a data-processing addendum, subprocessor list, and additional security documentation are available. Ask for them through our contact form.