HOW TO SECURE UPSTASH - SECURITY GUIDE | VIBEEVAL

Upstash Security Context

Upstash provides serverless Redis, Kafka, Vector, and QStash with a REST API designed for edge functions. The defining concern is the REST token: a single bearer token that grants whatever access the token’s permissions cover, sent on every API call from your serverless / edge function. Token leakage is the dominant incident shape — the token in NEXT_PUBLIC_*, the token in a public GitHub repo, the token in a deploy log.

Security Checklist

1. Treat REST tokens as production secrets

Tokens are JWT-like strings sent in Authorization: Bearer <token> on every request. Store in env vars (Vercel / Netlify / Cloudflare’s secret store), never in code, never in NEXT_PUBLIC_* / VITE_* (which ships to the browser), never in .env files committed to git. Use gitleaks in pre-commit.

2. Use read-only tokens by default

In Upstash Console → Database → REST API → Generate token: choose “Read-only” for tokens used by services that don’t write. Generate separate write tokens for write-capable services. The principle: a compromised read token can’t corrupt data.

3. Audit edge access patterns

Edge functions calling Upstash means the token is in the edge runtime’s env. Confirm: the edge platform encrypts env vars at rest (Vercel, Cloudflare yes), the runtime doesn’t log env values in error reports, and you don’t echo the token in any response (a debug response that returns the env can leak the token).

4. Verify TLS

Upstash REST API is HTTPS-only. Confirm your client uses https:// URLs (not http://). The Redis / Kafka protocol clients should also enforce TLS — verify in your driver’s connection options.

5. Configure team permissions

Org → Members: review quarterly. Anyone with admin access can read all data, generate tokens, and reset passwords. Remove ex-team members same-day; their tokens may still work until expired or rotated.

6. Understand serverless Redis security model

Upstash Redis is multi-tenant by default — your data is isolated by token, not by network. Confirm: every instance you create has a unique strong token, you don’t share tokens across instances, you’ve enabled TLS on the protocol port if you use the Redis protocol (not just REST).

7. Configure Kafka security

For Upstash Kafka: each topic has separate ACLs. Configure consumers and producers with topic-scoped credentials, not cluster-wide. SASL/SCRAM auth + TLS is the default — verify your client configures both.

8. Enable audit logging

For paid tiers: review platform-level audit logs for token creation, key access patterns, ACL changes. Stream to your SIEM if compliance requires it. Watch for: token creations you didn’t expect, traffic spikes, ACL changes.

9. Configure rate limiting at the application layer

Upstash itself rate-limits at the platform level (per plan), but for application abuse — login brute force, expensive read endpoints, LLM-call endpoints — implement per-user rate limits in your app, often using a Redis key counter as the rate-limit store. Upstash’s @upstash/ratelimit library is purpose-built for this.

10. Set sensible eviction policies

For Redis used as a cache: maxmemory-policy allkeys-lru (evict least-recently-used keys when full). For Redis used as a primary store: noeviction (reject writes when full) — but this means a single misuse can fill the database. Configure based on the data’s authority.

11. Use QStash signature verification

For QStash (HTTP-triggered jobs): your destination URL receives a signed payload. Verify the signature with the QStash signing key on every callback — without verification, an attacker can forge calls to your endpoint by guessing the URL. The Upstash-Signature header carries the signature.

12. Configure backups

For Redis with persistence requirements: enable backups in the Upstash console. Confirm retention matches your tolerance. Test restore once before you need it.

13. Configure Vector access

For Upstash Vector (semantic search): separate read and write tokens. Vector indexes can leak training data if you allow arbitrary similarity queries — for sensitive embeddings, restrict to specific query patterns rather than open similarity search.

14. Configure monitoring

In Console → Database → Metrics: review weekly for: traffic anomalies, error-rate spikes, evicted-key patterns. The Upstash dashboard surfaces baseline; for richer alerting, integrate with Datadog or your platform’s monitoring.

15. Plan for token rotation

Tokens don’t expire by default. Build a rotation policy: rotate every 90 days, after any team-member departure, after any exposure. Use a deploy hook that updates the env var and rolls the application.

16. Run a security scan

The full VibeEval scan tests your application’s bundle for exposed Upstash tokens and probes any application endpoints that proxy Upstash data for missing auth or BOLA.

Related Resources

Free Self-Audit Suite

Five free scanners.

Vibe Coding Security Risk Guide

Full risk catalogue.

Token Leak Checker

Free scanner for exposed tokens — catches Upstash tokens shipped to the browser.

Automate Your Security Checks

VibeEval scans applications using Upstash backends for exposed REST tokens and probes proxied endpoints for missing auth.