Security

Security on StackPicks is not a paragraph in the footer. It's a set of concrete controls baked into the stack from day one. This page documents the controls so you can decide whether to trust us with your data.

1. Encryption

• In transit — TLS 1.3 for browser ↔ server, TLS 1.2+ for server ↔ Supabase ↔ Razorpay
• At rest — Supabase Postgres uses AES-256 disk encryption; backups are encrypted
• Webhooks — Razorpay payment events are verified by HMAC-SHA256 signature before any DB write

2. Authentication

• Supabase Auth with secure session cookies (HttpOnly, Secure, SameSite=Lax)
• Passwords stored as bcrypt hashes — we never see your plaintext password
• Magic-link login available — no password to leak
• Sessions auto-refresh and rotate; rotation invalidates the prior token

3. Authorization (RLS)

Every table in our Postgres database has Row-Level Security enabled with explicit policies. The default in our system is “deny” — every read or write must match a policy.

• Public data (categories, published repos) — read-only, no writes from clients
• Owner-scoped data (sponsors, job posts) — only the owning user can read/write
• Premium-gated data — readable only while a premium subscription is active
• Sensitive tables (outbound clicks, newsletter subscribers) — service-role only, never exposed to the browser

4. Privacy controls in the analytics path

• No third-party advertising pixels — no Google Ads, no Meta pixel
• Cookie-free analytics — Plausible aggregates without identifiers
• IP hashing — outbound click tracking uses SHA-256 with a daily-rotating salt. The raw IP is never stored and the daily hash is uncorrelatable across days
• Server logs retained 14 days, then purged

5. Payment security

• All payments processed via Razorpay, PCI-DSS Level 1 certified
• Card numbers, UPI handles, and bank details are entered on Razorpay's domain — never on ours
• Razorpay payment signatures are verified server-side after every checkout
• Razorpay webhook signatures are verified before any database update — replay attacks fail
• We are not in PCI scope and do not store payment instruments

6. Hosting & infrastructure

• Database — Supabase, Mumbai region (ap-south-1), automated daily backups, point-in-time recovery on Pro tier
• Application — Vercel / Railway, automatic patching, isolated runtime per request
• DNS — secured with DNSSEC where the registrar supports it
• Email — Resend, SPF / DKIM / DMARC configured for the sending domain

7. Dependency hygiene

• pnpm audit runs in CI on every push; high-severity vulnerabilities block merge
• Dependabot opens upgrade PRs for security updates within 24 hours
• The dependency surface is intentionally small — we evaluate every new package before adding it

8. Incident response

• Suspected breach triggers immediate rotation of all service-role keys and session secrets
• Affected users are notified by email within 72 hours of confirmation, per the DPDP Act
• A public post-mortem is published if user data was confirmed exposed

9. Responsible disclosure

Found a vulnerability? We'd rather hear from you than from a third party. Email nuvexalearning@gmail.com with the subject SECURITY: <brief title>. Please include:

• A short description of the issue
• Steps to reproduce
• Impact assessment
• Your preferred name and contact for credit

We commit to:

• Acknowledging your report within 48 hours
• Providing an initial assessment within 5 business days
• Crediting you publicly (with your consent) once the fix ships
• Not pursuing legal action against good-faith researchers

10. What you can do

• Use a strong, unique password — or magic-link login
• Don't share credentials. We will never ask for your password by email or phone
• Verify payment confirmation emails come from @razorpay.com or our verified sending domain
• If anything looks off — unexpected invoice, weird email — email us first before clicking links