Security & Privacy
The protection layers currently present in Data Explorer, how they work, and the limits you should still understand before using the app with real data.
AES-256-GCM
Saved connection passwords are encrypted with AES-256-GCM before persistence. This is the primary backend protection layer for stored credentials.
Connection guardrails
Each connection can be configured as read-only, block schema changes, block import/export, or disable query execution entirely.
Secret enforcement
The backend refuses to boot if the JWT secret is too weak. Default admin credentials are replaced with random strings if environment variables are missing.
SSRF & Tunnel Guard
SSH Tunnels and outbound connections are strictly validated, blocking unauthorized access to internal networks (127.0.0.1, RFC1918 ranges).
What the app protects well today
- Credentials stored in the app database are encrypted with AES-256-GCM.
- SQL Guard blocks advanced bypass techniques like EXEC, EXECUTE in Read-only connections.
- SSRF guard strictly blocks internal or localhost targets (preventing intranet scanning via Tunnels), fails closed on empty hosts, and blocks IPv4-mapped IPv6 bypasses.
- Team privacy is isolated, removing insecure auto-sharing based on public email domains.
- Database error messages are sanitized to prevent sensitive infrastructure information leakage.
- Adversarial pentest suites run continuously, simulating identifier smuggling, CSRF header spoofing, and property-based fuzzing against every guard.
- A public security.txt documents the responsible disclosure channel for vulnerability reports.
Current session and sign-in behavior
Refresh token cookie
The app now uses a refresh token stored in an httpOnly cookie. That cookie is rotated on login, session refresh, and successful social-login exchange.
In-memory access token
The access token lives in client memory only. On reload, the frontend bootstraps the session through /auth/refresh instead of reading an older token from local storage.
This model is safer than localStorage-persisted JWT because the refresh token cannot be read directly by client-side JavaScript. For reliable cross-origin production behavior, you still need the correct FRONTEND_URL and HTTPS so secure cookies work end-to-end.
Read-only and connection policy controls
Server-side enforcement
Blocked operations such as UPDATE, DELETE, DROP, schema edits, import flows, or NoSQL mutations are rejected in the backend, not merely hidden in the UI.
AI actions still require review
Even when AI suggestions look reasonable, you should still review them before execution, especially for index creation, schema changes, and write queries.
Recommended best practices
- Use a strong JWT_SECRET of at least 32 bytes and an ENCRYPTION_KEY that is exactly 32 characters.
- Set ADMIN_EMAIL and ADMIN_PASSWORD in .env to prevent the system from using temporary random passwords.
- Prefer read-only connections for analytic queries to enable the SQL Guard protection layer.
- Always configure timeouts for large databases to prevent system resource exhaustion.
What is still worth doing next
Ready to explore data?
Join the community on GitHub to contribute to the smartest local database IDE.
Launch App