Security
How we protect your account.
A plain-English overview of how this site handles authentication, sessions, payments, and data. For the privacy side of the same story, see the Privacy Policy.
Sign-in
- Email and password. Passwords are hashed by Supabase Auth (bcrypt) — we never see or store the raw password.
- Password rules. Minimum length plus a server-side check against your last three password hashes, so you can't silently roll back to a previous one.
- Two-factor authentication (TOTP) — optional but recommended. Add a 6-digit code from an authenticator app (1Password, Authy, Google Authenticator, Bitwarden, etc.). You can enable, disable, or replace it any time from your account. We don't force it on.
- Backup codes. When you enable 2FA, you get ten single-use recovery codes. The codes you see are shown once; only SHA-256 hashes are stored.
- Captcha. Sign-up, sign-in, and password-reset forms are gated by Cloudflare Turnstile to keep automated abuse off the auth surface.
Sessions
- Sessions are stored in HTTP-only, secure cookies scoped to the site — page JavaScript can't read them.
- Every request refreshes the access token; the refresh path is invisible to you.
- An absolute 30-day session timeout — measured from when you signed in — bounds how long any single session can live, even if you stay active.
- Step-up auth (“sudo”). Hitting account or billing settings re-prompts you for your password, then keeps that confirmation valid for one hour before asking again.
Payments
Card numbers, CVVs, and expiry dates are handled entirely by Stripe — the same PCI-DSS Level 1 provider trusted by Amazon, Google, and Shopify. We never see or store raw card data. If a charge fails, the site only receives a yes/no signal and an opaque customer ID.
Data isolation
Every table in the application database has row-level-security policies enforced by Postgres. Even if application code had a bug, one user still cannot read or modify another user's profile, feed tokens, or subscription state. Service-role access is reserved for narrow server-side tasks (subscription webhook fan-out, admin-initiated deletion) and never reaches the browser.
All transactional and notification email flows through Resend. Every bulk-style message — new-post alerts, subscription receipts — carries an RFC 8058 one-click unsubscribe header, so Gmail, Yahoo, and Outlook can remove you with a single click. We don't use tracking pixels, open-rate beacons, or remarketing IDs.
Cookies
Strictly-necessary cookies (sign-in session, theme preference) are always on — they can't identify you to third parties. Analytics cookies load only with your consent via the cookie banner, and you can change or withdraw consent any time from Cookie preferences in the footer. We don't use advertising cookies.
Monitoring
Runtime errors are captured by Sentry with PII scrubbing on — stack traces and request metadata only. Cookies, form bodies, and auth headers are filtered at the SDK level before anything leaves the server.
Dependencies
The third-party surface area is intentionally small:
- Vercel — hosting, edge delivery, environment secrets.
- Supabase — Postgres and auth.
- Stripe — payments and subscription management.
- Resend — transactional and notification email.
- Cloudflare — captcha verification on unauthenticated forms.
- Sentry — error and performance monitoring.
- Google Analytics — aggregate page-view counts only, loaded only after you grant cookie consent.
All are SOC 2 Type II (or equivalent) and reviewed when they change. Application dependencies are reviewed and deployed through a standard CI flow.
Reporting a security issue
If you think you've found a security issue on the site, please use the report form and pick Security vulnerability as the category. Include enough detail to reproduce the issue — we'll acknowledge receipt within a business day and keep you updated through the fix. Please give us a reasonable window to remediate before any public disclosure.
For anything else, click Contact Support in the footer.