security at tellmarket.
We’re a small startup, so this page is written for two audiences: ordinary users who want to know “is my information safe?”, and security-curious folks (founders, investors, auditors) who want to know what we actually do. Wherever we use a fintech-grade third-party rather than rolling our own, we say so plainly — that’s a feature, not a shortcut.
we never see your card or your password
Payments go straight from your browser to Stripe. Card details never touch our servers. Stripe is PCI Level 1 certified (the highest standard for handling card data) and processes payments for Shopify, Lyft, Substack, and tens of thousands of others.
Passwords are handled by Supabase Auth using industry-standard hashing (bcrypt). We never see your plaintext password — not in our database, not in our logs, not even in transit.
data access is locked at the database layer
Our Supabase database uses Row Level Security: every query is automatically filtered to only the rows the logged-in user is allowed to see. Even if someone got hold of our public “anon” API key, they couldn’t read another user’s alerts, watchlist, or account state — the database itself refuses.
Privileged operations (granting Pro after a payment, sending alerts) use a separate “service-role” key that lives only on our server — never in the browser, never in the repository, never in client-side code.
all traffic is encrypted
Every request to tellmarket.app is HTTPS, enforced by both Vercel and our own configuration. We also send an HSTSheader (max-age 2 years) so that even if an attacker tried to downgrade you to insecure HTTP, your browser refuses.
payment events are cryptographically verified
When Stripe tells our server “this user paid,” we verify the message with Stripe’s webhook signature before granting Pro. A forged or replayed request will fail the signature check and be rejected. We also keep an idempotency ledger of every processed event id, so the same payment can’t accidentally grant Pro twice if Stripe re-delivers an event.
internal services authenticate with timing-safe secrets
Our ingestion bot talks to the website over a private API key (INTERNAL_API_KEY). The website verifies the key with a constant-time comparison — that prevents the class of timing-based attacks where an attacker measures how long each failed guess takes to learn the key one character at a time. The daily-recap cron uses a separate CRON_SECRET the same way.
we resolve and inspect every Pro user’s webhook URL
Pro users can configure a Slack or Discord webhook to receive arb alerts. Before sending anything, we resolve the hostname’s DNS server-side and reject the request if it points at a private range — loopback, RFC 1918 internal IPs, link-local, or cloud metadata endpoints (the famous 169.254.169.254). That blocks an attack class called SSRF (Server-Side Request Forgery) where a paying user would otherwise be able to trick our server into probing internal infrastructure.
email is signed, and unsubscribe is tamper-resistant
All emails go through Resend with DKIM and SPF records on our domain. Mail clients verify our signature before delivering — spoofed Tellmarket emails land in spam or get rejected outright.
The unsubscribe link uses RFC 8058 one-click POST. Email scanners and link-preview bots send GETs to every URL they see — if we accepted GET unsubscribes, those would silently unsubscribe real users. We don’t.
abuse-prone endpoints are rate-limited
Signup, login (OTP send), guest-checkout, and search all have per-IP rate limits backed by Upstash Redis (with an in-memory fallback if Redis is unavailable, so a denial of the rate limiter never opens the door wider). A bot trying to mass-spam our signup or burn our OTP-send budget will hit a wall within seconds.
we monitor errors and uptime
Application errors are reported to Sentry with stack traces and breadcrumbs, scrubbed of any user credentials. External uptime is monitored by UptimeRobot via our public /api/healthendpoint — if the ingestion service ever stops writing fresh market snapshots for more than 5 minutes, we get paged.
what we don’t have (yet)
We don’t hide what we haven’t built. We don’t currently have a SOC 2 or ISO 27001 audit — those are enterprise-procurement requirements that cost $50K+/yr to maintain and are overkill for our current size. We don’t have a bug-bounty program yet, but we respond to responsibly-disclosed issues within 24 hours.
We follow OWASP Top 10 protections, run automated dependency vulnerability scanning on every deploy, and put every code change through a multi-agent review before it ships. If you have specific security questions a CISO or auditor needs answered, email us and we’ll respond in detail.
reporting a security issue
If you find a vulnerability, please email kamyar@tellmarket.app with the details. We’ll acknowledge within 24 hours and keep you in the loop on the fix. We don’t threaten or litigate good-faith security researchers — the opposite, we’re grateful for the help.