Security - SlabScore

1. Overview

SlabScore takes account security and data protection seriously. This page describes the specific technical measures we use to protect your account, your portfolio data, and any payments you make. We update this page when our security posture changes — see the date at the top.

2. Encryption in Transit & at Rest

In transit: All requests to slabscore.io and its subdomains are served over HTTPS with modern TLS (1.2+). HTTP traffic is automatically redirected to HTTPS at the edge (Vercel).
HSTS: HTTP Strict Transport Security header is set on the apex domain — browsers refuse to load slabscore.io over plain HTTP for at least 6 months after first visit.
At rest: All data in Supabase (Postgres) is encrypted at rest using AES-256. Backups are encrypted with separate keys per Supabase's standard infrastructure.
Auth tokens: Supabase JWTs are stored in localStorage using PKCE flow. Tokens have 1-hour access expiry + 7-day refresh expiry; sign-out invalidates the refresh token server-side.

3. Payment Security (No Card Data Stored)

SlabScore never sees, processes, or stores your credit card number. All payments are handled by Stripe, a PCI-DSS Level 1 certified payment processor (the highest level — same as Amazon, Google, and Apple Pay).

Card numbers are entered directly into Stripe's hosted checkout — they never touch our servers.
We only receive a Stripe Customer ID + subscription status from Stripe webhooks.
Webhook signatures are verified server-side via Stripe's signing secret (no spoofing possible).
Refunds + plan changes are managed via Stripe's hosted Customer Portal.

4. Database & Row-Level Security

SlabScore uses Supabase (Postgres) for all user data. Every table that holds user-scoped data has Postgres Row-Level Security (RLS) policies enforcing that users can only read or write their own rows.

RLS on: profiles, subscriptions, saved_cards, batches, usage, push_subscriptions, and every other user-scoped table.
Server-only access: Administrative tables (admin_metrics_snapshots, stripe_events, feature_flags, promo_codes) have deny-all RLS with explicit service-role bypass — only server-side code using the service key can access them.
Service-role isolation: The Supabase service-role key is set as a server-side env var only. It is never bundled into client code or exposed via the public anon key.

5. Authentication & Access Control

Password hashing: bcrypt-equivalent hashing via Supabase Auth (we never see your password — it is hashed before it reaches our database).
Passkey support: WebAuthn-based passkey login available alongside password + Google/Discord OAuth. Use passkeys for the strongest account protection (phishing-resistant).
Session revocation: Sign-out invalidates the refresh token server-side; account deletion revokes all active sessions across all devices via auth.admin.signOut(userId, 'global').
Rate limiting: Auth endpoints are rate-limited per-IP (Upstash Redis); brute-force attempts trip the limiter within seconds.
Admin separation: Admin access is gated server-side via an explicit allowlist; admin actions are logged for audit review.

6. Third-Party Vendor Security

SlabScore uses these third-party services:

Vercel — hosting + CDN. SOC 2 Type II certified.
Supabase — database + auth. SOC 2 Type II certified; HIPAA-eligible.
Stripe — payments. PCI-DSS Level 1.
Resend — transactional email. SOC 2 Type II.
Anthropic — AI features (Claude Haiku). API key server-side only; cards never sent in payloads (only metadata).
PriceCharting — card price data. Read-only API; no user data sent.
Sentry — error monitoring. PII redaction enabled; we never send email addresses or payment data to Sentry.
Cloudflare R2 — encrypted off-platform database backups for disaster recovery.

7. Vulnerability Disclosure

If you find a security vulnerability in SlabScore, please report it to us at security@slabscore.io. We take all reports seriously and will respond within 72 hours.

Safe-harbor: we will not pursue legal action against good-faith security researchers who:

Avoid privacy violations, data destruction, or service degradation.
Test against your own accounts (not other users' data).
Give us reasonable time to respond before public disclosure (90 days minimum).
Do not exploit the vulnerability beyond what is needed to confirm it.

8. Incident Response

Known security incidents to date: 0. SlabScore has not experienced any known data breach, credential compromise, or successful account-takeover incident.

If a security incident occurs, we will:

Notify affected users via email within 72 hours of confirmed impact.
Publish a post-incident report describing what happened, what data was affected, and what we changed.
Reset affected credentials if applicable.
Coordinate with vendors (Supabase, Vercel, Stripe) where applicable.

9. Contact Security

For security-specific questions or reports, email security@slabscore.io. For general questions, use admin@slabscore.io.