HOW TO SECURE PLANETSCALE - SECURITY GUIDE | VIBEEVAL

PlanetScale Security Context

PlanetScale is a managed MySQL (Vitess) platform with branch-based schema workflows. The platform handles the infrastructure side — encryption at rest, network security, automated backups — so your residual surface is: who can access which branch, how connection passwords are issued, what queries the application sends, and whether deploy requests get reviewed before they hit main. Two recurring incident shapes: a development branch with a real-data clone and a wildly-permissive password set, and a connection password leaked to git that nobody rotates because “it’s just dev.”

Security Checklist

1. Generate scoped connection passwords

In Branches → [branch] → Connect → Create password: each password is scoped to a specific role (reader, writer, admin) and a specific branch. Generate a new password per service, never share across services. Storing in env vars (not code) is mandatory; rotation is one button click in the dashboard.

2. Enable branch-level safe migrations

Branches → [branch] → Settings → Enable safe migrations: prevents direct schema changes — every change must come via a deploy request. For production: this is on. For development: optional but recommended.

3. Configure branch permissions per team member

Org → Members: assign roles per team member. Reader (read-only on prod, full on dev), Writer (full on dev), Admin (full everywhere). Restrict prod write to a small group. Audit quarterly and on team-member departure.

4. Use deploy requests for schema changes

PlanetScale’s branch model: schema changes happen on a development branch, get reviewed via a deploy request, then ship to prod. Deploy Requests → Settings → Require approval: minimum one reviewer. Mirrors PR review for schema changes — catches “drop the wrong column” before prod.

5. Lock down connection strings

Connection strings include the password. Treat as a secret: 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 to catch accidental commits.

6. Enable audit logs

Org Settings → Audit Logs (Scaler+ tier): enable. Stream to your SIEM if compliance requires. Tracks: schema changes, password creations, member additions, branch creations.

7. Configure team permissions on sensitive branches

For branches with prod-cloned data: lock to the engineering team only. Marketing / sales / contractors should not have access to a branch with real customer data, even for “just analytics.” Use a separate analytics replica with PII masked.

8. Review deploy requests carefully

Every deploy request shows the schema diff and the affected rows estimate. For prod-bound changes: confirm the diff matches the intended change, run the change in staging first, schedule the deploy in a low-traffic window. Non-blocking schema changes don’t lock the table — but they do double-write while migrating, so plan capacity.

9. Use Vitess routing rules carefully

For sharded setups, vindex configuration determines which queries hit which shards. A misconfigured vindex can route queries to the wrong shard, returning unexpected data. Test routing changes in a development branch before deploying.

10. Require SSL connections

PlanetScale requires TLS by default — verify your driver actually enforces it. Connection strings include ?ssl=true or equivalent; if your driver silently downgrades to non-TLS, your connection is plaintext on the network path.

11. Monitor query insights

Insights → Slow Queries: review weekly. Slow queries are both a perf issue and a DoS surface (an attacker can trigger them). Add covering indexes for any slow query that processes user input.

12. Configure connection limits

In PlanetScale’s connection pooling: set per-application limits to prevent one misbehaving service from exhausting the pool. Use a connection pooler (Hyperdrive, PgBouncer-equivalent) at the application layer for serverless deployments.

13. Verify backup configuration

PlanetScale handles backups automatically. Confirm: backup retention matches your compliance requirement, restore-to-branch works (test once before you need it), backups are encrypted at rest (default).

14. Configure IP allowlisting

Branches → [branch] → Settings → IP allowlist (Enterprise tier): restrict connections to known application IPs. Reduces blast radius of leaked connection passwords.

15. Audit organization settings

Org Settings: review quarterly. Confirm: SSO is required, 2FA is required for all members, billing email is monitored, no leftover OAuth integrations from past tools.

16. Run a security scan

The full VibeEval scan tests your application’s queries for SQL-injection patterns and verifies BOLA across user IDs.

Related Resources

Free Self-Audit Suite

Five free scanners.

Vibe Coding Security Risk Guide

Full risk catalogue.

PostgreSQL Guide

Comparison reference for the closest open-source DB choice.

Automate Your Security Checks

VibeEval scans applications using PlanetScale backends — SQL-injection probing, BOLA across queries, connection-string exposure in the bundle.