HOW TO SECURE NEON - SECURITY GUIDE | VIBEEVAL

Neon Security Context

Neon is serverless Postgres with branching — full Postgres feature set including RLS, with dev branches that fork from prod data. The serverless architecture introduces two specific concerns: (1) connection strings are issued per-branch and per-role, and a leaked one is full DB access until rotated; (2) dev branches with prod-cloned data inherit prod data risk if granted to the wrong people. Otherwise the security profile is normal Postgres — see the PostgreSQL guide for the depth.

Security Checklist

1. Enable Row Level Security where applicable

For multi-tenant tables: ALTER TABLE my_table ENABLE ROW LEVEL SECURITY; plus per-operation policies keyed on the request’s user identity. RLS is full Postgres on Neon — same setup as Supabase or self-hosted Postgres.

2. Secure connection strings as secrets

Connection strings include the password. Store in env vars (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 any team-member departure or any exposure.

3. Configure branch permissions

Project → Settings → Roles: create per-branch roles. The production branch should not be writable by roles that only need development access. Role permissions inherit Postgres roles — define application-level least privilege at the role layer.

4. Use the Neon connection pooler safely

Neon’s built-in PgBouncer-compatible pooler runs in transaction-pool mode by default. Some Postgres features (prepared statements, LISTEN/NOTIFY, session-level settings) behave differently in transaction pooling — confirm your driver works with the mode you’ve selected. The pooler endpoint is a separate hostname from the direct endpoint; use the pooled one for serverless functions.

5. Understand serverless implications

Neon scales compute to zero between requests. The first request after a cold start has higher latency — confirm your driver’s connection-acquisition timeout accommodates this (≥ 5s is safe). For latency-sensitive workloads, configure the project to keep compute warm.

6. Configure IP allowlisting (Scale plan)

Project Settings → Network Security → IP Allowlist (Scale tier): restrict connections to known application IPs. Reduces blast radius of leaked connection strings.

7. Verify SSL

Neon requires TLS for all connections — verify your driver actually uses it. Connection strings include ?sslmode=require; if the driver silently downgrades, the connection is plaintext.

8. Configure team permissions

Project → Members: review quarterly. Owner / Admin / Member roles map to different levels of access. Remove ex-team members same-day.

9. Right-size compute

Project → Branches → [branch] → Compute: set the autoscaling range. Too small means slow queries; too large means a DoS amplifier (an attacker triggering an expensive query can scale you up and increase your bill). Set explicit limits.

10. Enable audit logging (Scale)

For Scale tier: integrate with Datadog / your SIEM. Track: schema changes, role creations, connection string generations, branch creations. Useful for incident response — “who created this branch and when.”

11. Use branches safely

A branch with prod-cloned data inherits prod data sensitivity. Don’t share branch connection strings broadly; treat dev-with-prod-clone like prod. For genuinely safe dev work, use anonymized data or schema-only branches.

12. Configure point-in-time restore

Neon’s branching enables time-travel — create a branch from a past point in time. Confirm the retention window matches your compliance requirement (default is 7 days, longer on paid tiers). Test the restore once before you need it.

13. Review autoscaling limits

Project → Settings → Compute: set explicit min and max compute units. The default may be unbounded, which means an unindexed query that scans a large table can scale up indefinitely until your card stops working.

14. Configure monitoring

Project → Monitoring: review weekly. Watch for: connection count anomalies, slow query growth, compute scale-up frequency. Each is a signal worth investigating.

15. Audit installed extensions

SELECT * FROM pg_extension; — review the list. Neon supports a curated subset of Postgres extensions; for ones you’ve enabled, confirm they’re patched to the current version.

16. Run a security scan

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

Related Resources

PostgreSQL Guide

Full Postgres security guide — applies to Neon directly.

Supabase Guide

Comparison reference for the closest managed alternative.

Free Self-Audit Suite

Five free scanners.

Automate Your Security Checks

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