UPSTASH SECURITY CHECKLIST

Upstash exposes Redis, Kafka, and Vector over both Redis protocol and HTTP REST — which is the source of its serverless friendliness and its most common security failure. The HTTP token is easy to use from the browser, which means it ends up in the browser bundle, granting any visitor full read/write to your cache, session store, and rate-limit state. The checklist below is what we look for first when we audit an Upstash-backed app.

Treat Critical as launch-blocking. High is week-one. Medium is the cleanup once you have users.

How to use this checklist

Walk it once in the Upstash dashboard for your production database, ticking items as you go. After the whole list passes, scan the app that connects to verify no client-side leak undoes the database-side hardening.

Critical (fix before launch)

1. Use REST tokens scoped to read-only or write-only

Why it matters. Upstash issues two REST tokens by default: a master token (full read/write) and a read-only token. AI-generated code routinely picks the master token because it’s listed first. Used from a Next.js API route that’s actually a 'use client' function, the master token ends up in the browser bundle.

How to check. Decode each token your app uses. Confirm services have only the permissions they need; reads-only services use the read-only token; writes happen only from server contexts.

How to fix. For client-bundled code, use the read-only token (or no token at all — proxy through a server route). Move write operations to server actions or API routes.

2. Enable IP allowlisting on production databases

Why it matters. Upstash’s IP allowlist limits which networks can connect. Without it, anyone with the connection string can connect from anywhere — and the connection string is small enough to memorize after one glance.

How to check. Database → Network. Confirm IP allowlist contains only your app’s outbound IPs.

How to fix. Add the IP ranges of your app hosting. For platforms with rotating IPs, use a NAT gateway with a stable IP.

3. Strip Redis URL credentials from any client-bundled code

Why it matters. A connection URL like redis://default:<password>@<host>:6379 grants full database access. If it ends up in NEXT_PUBLIC_* or VITE_*, it ships in the bundle. AI tools do this by default when wiring up “client-side caching”.

How to check. Search the codebase for redis://, rediss://, and any var named REDIS_URL, UPSTASH_REDIS_URL. Confirm none are in NEXT_PUBLIC_* or VITE_*. Search the deployed bundle for the same patterns.

How to fix. Move all Redis access to server-side code. The client never sees the URL.

4. Configure TLS-only connections

Why it matters. Upstash supports both redis:// (plaintext) and rediss:// (TLS). Production connections should always use TLS. Plaintext on a shared network exposes every command.

How to check. Confirm app config uses rediss://. In the Upstash dashboard, check whether the database accepts plaintext connections at all.

How to fix. Switch to rediss://. Disable plaintext at the database level if your plan allows.

5. Audit which keys hold session tokens

Why it matters. Apps using Upstash for sessions store JWTs or session cookies as values keyed by user ID. If your master token leaks, the attacker reads every session and can hijack any account.

How to check. In the Upstash CLI: KEYS sess:* (or your prefix). Audit how many keys hold authenticatable session data.

How to fix. Encrypt session values at rest using a key your app holds (defense in depth — the master token leak still works for invalidation but not for hijacking). Set short TTLs on all session keys.

6. Verify the master token is not used by long-lived services

Why it matters. Master tokens grant FLUSHALL, CONFIG, and every administrative command. App services that crash through user input — or that get exploited via SQL injection in adjacent stores — can use those commands to wipe the database.

How to check. Audit which services use which token. Master tokens should be reserved for migrations, ops scripts, and explicitly admin tooling.

How to fix. Issue per-service tokens with the minimum permission set. Use the read-only token for cache reads; issue write-scoped tokens for specific key prefixes.

High (fix in the first week)

7. Set token expiry on issued REST tokens

REST tokens with no expiry are permanent. Set expiry on every issued token — long enough to be useful, short enough that a leak is bounded.

8. Configure max-memory and eviction policies

Default eviction can surprise apps that rely on Redis as a primary store rather than a cache. Set maxmemory-policy explicitly per database based on workload.

9. Enable audit logging on production

In Pro/Enterprise, audit logs record administrative actions. Ship them to your SIEM.

10. Verify rate-limit state is not exposed

If you use Upstash for rate limiting (@upstash/ratelimit), confirm the keys are not readable from the client. A client that can read its own rate limit can reset it.

11. Use prefixes per service to limit blast radius

Prefixing keys per service (auth:*, cache:*, rate:*) means a compromised service can only damage its own prefix — provided you issue prefix-scoped tokens.

12. Restrict who can rotate tokens

Token rotation requires admin access. Audit who has it; restrict to the smallest possible group.

Medium (fix when you can)

13. Document which databases serve which environments

Production, staging, dev — make the mapping explicit.

14. Set up backup verification

Upstash has automated backups; test restores periodically to confirm they work.

15. Pin client SDK version

@upstash/redis evolves; pin the version per app and audit changelog before bumping.

16. Set up alerting on request-count anomalies

A sudden spike in reads or writes is either an attack or a runaway service. Alert on outliers.

17. Audit which databases each team member can access

Upstash team roles control who can see databases and rotate tokens. Audit; restrict where you can.

18. Restrict who can FLUSHALL

Even on per-service tokens, ensure none have FLUSHALL or FLUSHDB permissions unless explicitly required.

After every token issuance

• Verify scope (which database, which permissions, which key prefix).
• Verify expiry is set.
• Document where the token is used.
• Plan the rotation date.

Common attack patterns we see in Upstash apps

The master-token-in-bundle. AI-generated Next.js code stored UPSTASH_REDIS_REST_TOKEN as NEXT_PUBLIC_* “for client-side caching”. Token shipped in bundle; visitor uses it from DevTools to dump every key.

The plaintext rediss vs redis swap. App config used redis:// instead of rediss://. Connections through the cloud provider’s internal network were plaintext; an internal compromise read every command.

The shared session store. Same Upstash database used by staging and production. Staging compromise (which had broader access for testing) reads production sessions.

The unrestricted FLUSHALL. Attacker exploits the app, uses the master token to FLUSHALL. Cache empties; database (which Upstash was fronting) collapses under the load.

Related Resources

How to Secure Upstash

Step-by-step guide for hardening an Upstash deployment — token strategy, prefix design, IP allowlisting, and the rate-limit hardening above in long form.

Is Upstash Safe?

In-depth analysis of Upstash’s defaults — what tokens grant, what’s encrypted, and what we find when we audit a typical Upstash-backed app.

Automate Your Checklist

A checklist tells you what to look for. A scanner tells you what’s actually broken in the deployed app that connects to your database. VibeEval scans the app, attempts the master-token-in-bundle and rate-limit-bypass attacks above, and reports what got through.