HOW TO SECURE RETOOL - SECURITY GUIDE | VIBEEVAL

Retool Security Context

Retool builds internal tools that connect directly to your databases and APIs. Two distinct risks: (1) the resource — a Retool resource is a connection with credentials, and the credential is shared by everyone with access to any app using it; (2) the app permissions — once a resource is connected, every app and every user with edit access can run any query against it. The recurring incident shape is a contractor with edit access who can write a DELETE FROM users query against the production database resource.

Security Checklist

1. Use read-only database connections by default

In Resources → [resource] → Edit: connect with a read-only database user. Create write-capable resources separately and grant access only to the apps and roles that need them. Halves the blast radius of any compromised user account.

2. Implement RBAC at the app and group level

Settings → Groups: create groups (Admins, Support, Read-Only) and assign apps + resources per group. Avoid the default “all users see all apps” — every app a user can see is an app they can run queries against.

3. Store credentials in Retool’s encrypted vault

For API keys / tokens used in REST resources: use Resources → Configuration Variables or the per-resource credential field. Never paste secrets into a query template’s interpolation — they end up in the query history and the audit log.

4. Configure query approval flows for destructive ops

For queries that DELETE / UPDATE in bulk or run on production resources: enable Query → Run Behavior → Require approval before run. Approval flows force a second human to confirm before the query fires.

5. Enable SSO

Settings → Single Sign-On: configure SAML / OIDC with your IDP (Okta, Google Workspace, Azure AD). Map Retool groups to IDP groups so removing someone from the IDP automatically removes Retool access.

6. Configure audit logging

Settings → Audit Log (Enterprise): enable detailed logging. Stream to your SIEM (Splunk, Datadog, S3). Useful for incident response — “which user ran this query at this time” is the first question after any data leak.

7. Audit resource-to-app mapping

Resources → [resource] → Apps using this resource: review the list. A resource connected to production should not appear in apps used by unintended teams.

8. Configure IP allowlisting

For Retool Cloud: Settings → Security → IP Restrictions: limit access to office / VPN IPs. For Retool Self-Hosted: front it with a load balancer that enforces the same. Reduces credential-leak blast radius.

9. Require 2FA for all users

Settings → Security → Two-factor authentication required: on. Retool’s compromised-credential blast radius is “every database the user has access to” — 2FA is the cheapest control.

10. Audit custom JavaScript transformers

Custom JS in transformers runs in the user’s browser with full Retool app context. Audit for: hardcoded credentials (rotate immediately), eval (which executes arbitrary strings), API calls to domains you don’t recognize.

11. Configure environment variables per environment

Settings → Environment Variables: separate dev, staging, prod. Apps in the dev environment should never have production credentials available — even read-only.

12. Verify webhook security

For webhooks called by Retool (or webhooks that trigger Retool workflows): verify the signature on the receiving side, use HTTPS only, never include secrets in URL parameters. See Stripe webhook and paid-trust for the verification pattern.

13. Configure data retention

For Retool Cloud: review the audit log retention (often 30-90 days by default). For compliance workloads: ensure you can export logs to a longer-retention store.

14. Review embedded apps

If you embed Retool apps in other applications: confirm the embed token has minimum scope, the embedding origin is allowlisted, and the user identity passed to Retool matches the user’s identity in the host app.

15. Test user permissions across roles

Walk through each group’s permissions: log in as a member of each group, confirm they can only see apps they should and only run queries they should. The Retool perms model is layered (org → group → app → query) — a permission that looks restricted at one layer may be overridden at another.

16. Run a security scan

For internal-facing tools, public-facing scanners are less useful. Audit by walking through user flows and comparing observed behaviour to expected RBAC.

Related Resources

Free Self-Audit Suite

Five free scanners.

Vibe Coding Security Risk Guide

Full risk catalogue.

Automate Your Security Checks

VibeEval focuses on customer-facing apps; for internal tooling like Retool, the audit is RBAC and credential hygiene rather than DAST. The general checklist still applies for the apps that surface Retool data publicly.