TURSO SECURITY CHECKLIST

Turso is libSQL/SQLite-as-a-service with edge replication. Two patterns make Turso security tricky: tokens are long-lived and broadly scoped by default (org-level admin tokens are common in .env), and embedded replicas put a literal SQLite file containing your data on every machine that runs the app — which sometimes ends up in container images, in unattended dev laptops, and in CI artifacts. The checklist below is what we look for first when we audit a Turso-backed app.

Treat Critical as launch-blocking. High is week-one. Medium is the cleanup once the database is in production.

How to use this checklist

Walk it once via the Turso CLI and dashboard for your production database, ticking items as you go. After each fix, run the same scan against staging and dev databases — the security properties should be tighter on production but not absent on staging. After the whole list passes, scan the app that connects to the database.

Critical (fix before launch)

1. Use scoped tokens per service, never master tokens

Why it matters. Turso CLI’s default workflow generates an org-level admin token for “easy setup”. App services that use this token can create databases, delete databases, and rotate other tokens. A leaked admin token is the entire org.

How to check. Decode each token your services use (the JWT body lists the permissions). Confirm tokens used by app services are scoped to a single database with read-only or read-write permissions, not org-level admin.

How to fix. turso db tokens create <db-name> --read-only (or --expiration <duration>). Switch services to scoped tokens; revoke admin tokens used in apps.

2. Enable replica access controls

Why it matters. Embedded replicas put a SQLite file with your data on every machine that runs your app. If the app is deployed to multiple environments with the same token, all those replicas share the same data — including any PII.

How to check. List every machine / container that has run the app with embedded replicas enabled. Audit which environment’s data each replica should hold.

How to fix. Use per-environment tokens for embedded replicas, with each token scoped to that environment’s database. Don’t share tokens between staging and production.

3. Restrict embedded replica file paths

Why it matters. Embedded replicas write a SQLite file to disk. If the path is world-readable (/tmp/app.db, ./data/replica.db), other processes on the machine — or other containers on a shared host — can read every row.

How to check. Audit the replica path in your app code. Confirm it’s under a restricted directory (/var/lib/<your-app>/) with mode 0700.

How to fix. Move the replica to a non-world-readable path. Set explicit chmod 600 on the file. For containers, mount it on a volume with appropriate permissions.

4. Audit which databases share a group

Why it matters. Turso groups co-locate databases for replication and billing. Databases in the same group can sometimes share auth or replication paths in ways that surprise teams. A leaked token in one database in the group can affect adjacent databases.

How to check. turso group list and turso db list. Confirm production and dev databases are in different groups.

How to fix. Move dev databases to a separate group. For multi-tenant apps, give each tenant its own database (Turso is cheap enough that this is usually fine).

5. Rotate tokens after team-member changes

Why it matters. Tokens are long-lived. When a developer leaves the team, any token they had — admin or scoped — keeps working until you rotate. Same for any token they generated for ad-hoc tasks.

How to check. Audit turso db tokens list and the org token list. Cross-reference against current team membership.

How to fix. Rotate any token associated with a former team member. For active members, rotate on a schedule (quarterly).

6. Confirm tokens have expiry set

Why it matters. Tokens with no expiry are permanent. Leaked → exploitable forever. Tokens with expiry self-revoke if forgotten.

How to check. turso db tokens list and inspect the expiry. Tokens with no expiry are common because the CLI defaults to permanent.

How to fix. Re-issue with --expiration 30d (or your team’s chosen window). Automate rotation in CI.

High (fix in the first week)

7. Use schema-scoped tokens for app services

Turso supports tokens scoped to specific schemas / tables (in newer versions). Use these to give app services access only to what they actually use.

8. Audit replica replication targets

Each embedded replica connects to a primary. Audit which primary each replica points to. A replica pointing at the wrong primary can mix data across environments.

9. Enable token expiry by default in CI

CI pipelines that generate tokens for testing should always set short expiry (< 1 hour). Long-lived CI tokens are a leak waiting to happen.

10. Set up monitoring on token usage

Turso emits per-token request metrics. Alert on unusual patterns: a token that’s normally idle suddenly making 10,000 requests is either a runaway service or an attack.

11. Use the libSQL client with TLS verification

The libSQL client supports TLS by default, but configurations sometimes disable verification “for testing” and forget to re-enable. Confirm production clients verify the certificate.

12. Audit who can create tokens at the org level

Org-level admin can issue admin tokens. Restrict who has admin to the smallest group.

Medium (fix when you can)

13. Document which databases serve which environments

A short table: prod-app-1 → production, staging-app-1 → staging, dev-* → developer-owned. Saves a lot of “wait, which database is this?” moments.

14. Pin libSQL client version

The client evolves; pin a specific version per app and audit changelog before bumping.

15. Set up backup verification

Turso supports point-in-time restore and dumps. Periodically test a restore to a scratch database; confirm the data restores.

16. Restrict who can delete databases

Database deletion is destructive; reverse only via backup. Restrict the role.

17. Audit installed extensions on each database

libSQL supports extensions. Keep the list minimal; pin versions.

18. Set up alerting on group-level changes

Group membership changes (database moves, new replicas) are unusual events worth alerting on.

After every token issuance

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

Common attack patterns we see in Turso apps

The org-level admin token in production. Service deployed with the first token ever generated, which was admin-scoped. App gets exploited; attacker can create new databases (for crypto-mining), delete production data, or pivot.

The shared embedded replica. Container image baked with a SQLite replica file containing real user data. Image is public on Docker Hub. Replica file is dumpable.

The cross-environment token. Same token used in staging and production “for convenience”. Leaks in staging logs; works against production immediately.

The forgotten developer token. Developer left six months ago; their personal admin token still works. Attacker who finds an old laptop can connect to production.

Related Resources

How to Secure Turso

Step-by-step guide for hardening a Turso deployment — token strategy, embedded replica configuration, group hygiene, and the rotation patterns above in long form.

Is Turso Safe?

In-depth analysis of Turso’s defaults — what tokens grant, what replicas expose, and what we find when we audit a typical Turso-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 SQL injection and credential-leak vectors, and reports what got through.