Security overview
The safeguards Schmatz uses, the limits of those safeguards, and how to report a security problem. This is an early-stage service, not a claim of certification or a guarantee that an incident cannot occur.
Scope
This overview describes the current application and production deployment as of the date above. Controls can change as the service develops. The separate privacy policy describes what personal information is processed.
Identity and authentication
- Auth.js manages signed sessions and supports one-time email links and Google OAuth; Schmatz does not store account passwords.
- Email sign-in links are single-use and expire after 30 minutes. Resend delivers those messages, and Google participates only when a user chooses Google sign-in.
- Users may enable time-based one-time-password two-factor authentication from Settings. Recovery codes are stored as hashes; the TOTP seed remains sensitive server-side data.
- Session, CSRF, OAuth-state, and related cookies use Auth.js security controls. Production session cookies are secure and HTTP-only.
Network and transport
- Public browser traffic is served over HTTPS.
- The Next.js application and FastAPI service are bound behind the public edge; the FastAPI service is not intended to be directly reachable from the internet.
- Security headers and proxy rules reduce common browser and header- spoofing risks. Administrative access is separate from normal user access.
Application and data controls
- Protected routes resolve the Auth.js session server-side, and operator-only routes enforce a separate role check.
- User input is validated and database queries use parameter binding. Public forms and costly research endpoints apply rate or entitlement limits.
- Personal and research data is stored in SQLite with operating-system access controls. The database is not exposed as a public query service.
- Deployment takes a database backup before migrations. Nightly backup tooling creates consistent snapshots and rotates daily, weekly, and monthly copies in operator-controlled object storage when configured.
- Secrets are supplied through deployment configuration rather than intentionally embedded in customer-facing code. Automated checks scan for secret and data-boundary regressions.
Service providers
Security also depends on the providers used for hosting, proxying, backups, email, Google authentication, AI responses, and Stripe billing if payments apply. Those providers maintain their own controls. A compromise of an operator account, infrastructure provider, or production host could expose data available to that system.
What we do not claim
Schmatz does not currently claim:
- SOC 2 or ISO 27001 certification
- PCI DSS certification by Schmatz; payment details are handled by Stripe
- HIPAA compliance
- A completed independent penetration test
- A formal bug-bounty or coordinated-disclosure program
- That any system is invulnerable or that data loss is impossible
Incident response
If we learn of a security incident, we will work to contain it, preserve relevant evidence, understand the affected systems and data, restore safe operation, and notify affected people or authorities when required by applicable law. The timing and detail of any notice depend on what can be confirmed without creating additional risk.
Report a vulnerability
Use the security contact form or email [email protected]. Include the affected URL, what you observed, steps to reproduce, and a safe way to contact you. Do not access, change, or delete data that is not yours, disrupt the service, or publicly disclose an issue before there has been a reasonable opportunity to investigate it.