HOW TO SECURE TURSO - SECURITY GUIDE | VIBEEVAL

Turso Security Context

Turso is libSQL (SQLite fork) at the edge with embedded replicas. Two unique surfaces relative to traditional databases: (1) tokens are scoped per-database and per-permission, and a leaked token gives whatever access the token granted; (2) embedded replicas mean a copy of the data lives on the client (or edge node) and syncs from primary — the primary’s auth controls writes, but the local replica’s data is locally readable. Token hygiene and replica deployment topology are the main configuration concerns.

Security Checklist

1. Generate scoped tokens per service

turso db tokens create <db-name> --read-only for services that only read. Full-access tokens for services that need writes. Never share a token across services — one rotation breaks everything connected. Per-service tokens scope the blast radius of any leak.

2. Store tokens in environment variables

Tokens are JWT-like strings, copy-paste-able. Treat as secrets: store in env var (Vercel / Netlify / Cloudflare / your platform’s secret store), never in code, never in .env files committed to git. Use gitleaks in pre-commit. Rotate after exposure or team-member departure.

3. Use read-only tokens by default

Most application code reads more than it writes. Default to a read-only token; create a separate write token for the specific routes that need it. The principle: a compromised read token can’t corrupt the data.

4. Configure database group access

Turso groups let multiple databases share infrastructure. Group → Members: review who has access. Anyone with group access can interact with all databases in the group — for tenant isolation, use separate groups per tenant or per environment.

5. Understand embedded-replica security

Embedded replicas sync from the primary to a local SQLite file on the client / edge. The local file is locally readable — any process on the host with file access reads everything. For server-side embedded replicas (in serverless functions, on edge workers), this is fine. For client-side embedded replicas (mobile apps, desktop apps): assume the data is exposed to the device’s user.

6. Enable audit logging

For paid tiers: review platform-level audit logs for token creation, database access patterns, schema changes. Watch for: token creations you didn’t expect, queries from unusual IPs, sudden traffic spikes.

7. Configure team permissions

Org → Members: review quarterly. Owner / Admin / Member roles map to different access levels. Remove ex-team members same-day; their tokens may still work until expired.

8. Use libSQL features safely

libSQL extensions to SQLite (HTTP API, replication) have additional auth surfaces. The HTTP API uses the same token-based auth as the libSQL protocol — same hygiene rules apply.

9. Configure sync intervals for replicas

For embedded replicas: choose sync interval based on consistency vs cost trade-off. Frequent sync = closer to primary state, more network traffic, more compute. The interval doesn’t directly affect security but affects how stale a stolen replica’s data is.

10. Review schema changes carefully

turso db shell <db> then .schema to see the current schema. Schema changes are not gated by deploy-request workflows in Turso (unlike PlanetScale) — anyone with a write token can ALTER TABLE. Restrict the write-token-issuing role to a small group.

11. Configure backups

Turso provides automated backups. Confirm: retention matches your requirement, restore-to-new-database works (test once before you need it). For disaster recovery, also dump SQL exports periodically to your own storage.

12. Understand replica security model

Each replica has read access to whatever its token allows. A replica that’s read-only can’t corrupt data, but its local file is still locally readable. Plan replica placement (which edges, which servers) with the local-file-readability assumption in mind.

13. Configure monitoring

For paid tiers: integrate with Datadog or similar. Watch for: token usage anomalies, query rate spikes, schema-change events. Each is worth investigating.

14. Set query size limits

In your application driver: enforce reasonable query response size limits so a SELECT * over a large table doesn’t blow up the client. Server-side, use LIMIT clauses on every list query that doesn’t paginate.

15. Plan for token rotation

Build token rotation into your deploy pipeline: a token age threshold (90 days) triggers rotation. Use a deploy hook that updates the env var and rolls the application. Without a rotation plan, tokens accumulate and a leak from any era is still active.

16. Run a security scan

The full VibeEval scan tests your application’s SQL queries for injection patterns and BOLA across queries. SQLite’s flat-table-no-RLS model means application-level filtering is the only data-isolation boundary — extra reason to test.

Related Resources

Free Self-Audit Suite

Five free scanners.

Vibe Coding Security Risk Guide

Full risk catalogue.

PostgreSQL Guide

Comparison reference if you need RLS-style row filtering.

Automate Your Security Checks

VibeEval scans applications using Turso backends for SQL-injection patterns, BOLA, and exposed tokens.