Security overview

Scope

This overview describes security controls as of the date at the top of this page. The controls evolve as the product matures. We will update this page when material changes are made.

Identity & authentication

Authentication is self-hosted. Schmatz runs Auth.js v5 (the open-source library, formerly NextAuth) on its own server; there is no third-party identity provider sitting in the loop. Magic-link sign-in emails are delivered via Resend, which processes recipient addresses solely for delivery. We never set, store, or transmit passwords — sign-in is passwordless via email magic links or Google OAuth. Auth.js handles:

• Magic-link token generation, single-use verification, and expiry (30-minute window)
• Session JWT signing and verification using a server-side secret never exposed to the browser
• Google OAuth code-exchange and account linking
• CSRF protection on every authenticated mutation

The full Auth.js threat model and security documentation is at authjs.dev/security. Resend's posture is documented at resend.com/legal/security.

Network & transport

• All public traffic to Schmatz is served over HTTPS with a TLS certificate issued by a recognized certificate authority. There is no HTTP-to-HTTPS downgrade path on the public surface.
• Internal services (the FastAPI bridge that serves the dashboard) are not directly exposed to the public internet. They sit behind a reverse proxy on the same VM and are only reachable through the Schmatz hostname.
• Operator-only administrative access happens through a private overlay network (Tailscale), not over the public internet.

Data at rest

• Account information and behavioral telemetry live in a SQLite database on the operator's VM. The VM's disk is encrypted at the operating-system layer.
• Periodic backups of the database are stored on operator-controlled storage and are deleted on a rolling 90-day window.

Access controls

• You can only access your own account data through the dashboard. API endpoints verify your Auth.js session JWT before responding.
• Operator access to the VM is limited to a single SSH key, held by the operator and restricted to a private Tailscale tailnet. There are no shared credentials.
• Third parties — Resend handles delivery of magic-link sign-in emails (sees the recipient address and email body). Google OAuth (only if you sign in with Google) sees your authentication request. Cloudflare proxies HTTP traffic and provides DDoS / WAF protection.

Application security

• Schmatz applies the same authentication gate to every API endpoint via a single FastAPI middleware. Routes are never silently public.
• Inputs to internal scripts come from a known set of public-domain and freely-redistributable data sources; user input never reaches a SQL query without parameter binding.
• Dependencies are tracked in requirements.txt and package.json; we update them on a best-effort basis when CVEs are flagged.
• Cloudflare WAF + Bot Fight Mode sit in front of the application as a network-layer defense; per-IP rate limits on authentication endpoints provide additional protection against credential-stuffing.

What we don't claim

To be honest with you about our security posture: Schmatz does not currently hold:

• SOC 2 Type I or Type II attestation
• ISO 27001 certification
• PCI DSS certification (we do not handle card data directly — Stripe will handle that when payments launch)
• HIPAA compliance (we do not handle health data)
• A formal external penetration test
• A formal vulnerability-disclosure program

We will pursue an appropriate subset of these — most likely SOC 2 Type I — as the user base grows and warrants it. Today’s early-stage release is targeted at users who can make an informed risk decision about participating without these attestations.

Incident response

If we detect or are notified of a security incident affecting your data:

1. We will investigate and contain the incident as quickly as possible.
2. We will notify affected users by email at the address on file as soon as we have reliable information about scope and impact.
3. For incidents affecting Washington-resident PII, we will comply with the notification requirements of RCW 19.255.
4. We will publish a public post-mortem describing what happened, what data was affected, and what changes we are making to prevent recurrence.

Reporting a vulnerability

If you discover a security vulnerability in Schmatz, please report it through the beta channel by which you received your invitation, marked "SECURITY". We appreciate good-faith reports and will work with you to understand and remediate the issue. We do not currently offer monetary bug bounties.

We ask that you:

• Do not access, modify, or delete data that is not yours, beyond what is strictly necessary to demonstrate the vulnerability
• Do not disrupt service for other users
• Give us a reasonable window to remediate before public disclosure

Reference framework

The controls described above are organized in a manner consistent with the NIST Cybersecurity Framework (Identify / Protect / Detect / Respond / Recover) but Schmatz does not claim certification against NIST CSF or any specific framework. The framework reference is informational.