# How to Secure Retool Applications

- Tool: Retool
- Difficulty: Beginner
- Time required: 30-45 min
- Compatibility: Retool Cloud and Self-hosted
- Last updated: March 2026

## TL;DR

Securing a Retool app requires five layers: authentication (SSO + MFA), authorization (RBAC + per-app permissions), secret management (configuration variables + resource credentials), audit logging (Business+), and network controls (IP allowlisting or self-hosted VPC deployment). This guide walks through each layer with specific settings and best practices.

## A Layered Security Strategy for Retool

Retool applications often access sensitive business data — customer records, financial information, internal APIs. A single misconfigured permission or exposed API key can lead to a data breach. Securing Retool requires thinking in layers: who can log in, what they can do, what data they can see, how credentials are stored, and how activity is monitored.

This tutorial covers Retool's security features systematically — from authentication configuration to self-hosted network isolation. Some features are plan-gated: SSO is available on Business+, audit logs on Business+, and advanced network controls require self-hosted or Enterprise. Even on Free and Pro plans, there are meaningful security improvements you can make.

Retool is SOC 2 Type II certified and offers IP allowlisting, SAML 2.0 SSO, SCIM provisioning, and granular permission scopes. This tutorial shows you how to configure each.

## Before you start

- Admin access to a Retool organization
- Understanding of basic security concepts (authentication vs authorization, encryption at rest)
- An identity provider (Okta, Azure AD, Google Workspace) for SSO setup — optional but recommended
- For self-hosted sections: access to your Retool deployment environment (Docker, Kubernetes)

## Step-by-step guide

### 1. Configure SSO and enforce it for all users

Navigate to Settings → Authentication. Enable SAML 2.0 or OIDC SSO with your identity provider (Okta, Azure AD, Google Workspace, OneLogin). After configuring SSO, enable 'Enforce SSO' to prevent users from logging in with email/password. This centralizes authentication in your IdP, enabling MFA enforcement and deprovisioning through your existing directory. On Business+, also configure SCIM for automatic user provisioning and deprovisioning.

**Expected result:** Users are redirected to your SSO provider on login. Email/password login is disabled. New users are automatically provisioned through SCIM.

### 2. Review and tighten RBAC permission groups

Go to Settings → Roles & Permissions. Audit each user's group membership. Apply the principle of least privilege: Viewer access for end users who only run apps, Editor for app builders, Admin only for infrastructure owners. On Business+, create role-specific custom groups (Finance, Support, HR) with only the necessary permission scopes. Remove users from Admin who do not need full access.

```
// Principle of least privilege in Retool:
// End users who run apps → Viewer group
// App developers → Editor group
// DevOps / IT / Security → Admin group

// Business+ custom group example: Support
// ✓ Use apps
// ✓ View app list  
// ✗ Create apps
// ✗ Manage resources
// ✗ Access settings
// ✗ View audit logs
// ✗ Manage users
```

**Expected result:** Each user has the minimum permissions needed for their role. Admin group is small and auditable.

### 3. Move all credentials to secure storage

Audit your apps for hardcoded API keys, passwords, or tokens. Move any found into either Configuration Variables (Settings → Configuration Variables, marked as secret) or Resource credential settings. Delete the hardcoded values from queries and app definitions. Resource credentials are the most secure option as they are injected server-side and never reach the browser. Configuration variables marked as secret are write-only and cannot be read by any user after entry.

**Expected result:** No API keys, passwords, or tokens appear in any query body, component value, or JS Query as plain text.

### 4. Configure per-app access control

For each sensitive app, review its sharing settings (Share button, top-right). Set the minimum required access. Avoid making sensitive apps available to 'All Users' if only a subset of your org needs them. Assign specific groups (Finance, Managers) to sensitive apps. Inside apps, use {{ current_user.groups.includes('finance') }} in component Hidden properties to further restrict specific features within the app.

```
// In sensitive apps — Inspector Hidden property examples:

// Hide salary data column for non-HR/Admin users:
{{ !current_user.groups.some(g => ['hr', 'admin'].includes(g)) }}

// Hide delete button for non-admin users:
{{ !current_user.groups.includes('admin') }}

// Show read-only view for viewers:
{{ current_user.groups.includes('viewer') && !current_user.groups.includes('admin') }}
```

**Expected result:** Sensitive apps are only accessible to users who need them. Within apps, sensitive actions and data are restricted by role.

### 5. Enable audit logging and set up monitoring (Business+)

Go to Settings → Audit Log. Enable audit logging to capture all user activity: query executions, app edits, login events, permission changes. On Enterprise plans, stream audit logs to Datadog, Splunk, or another SIEM via the log streaming configuration. Set up alerts for suspicious patterns: after-hours access, bulk data exports, failed login attempts, or privilege escalation.

**Expected result:** Audit logging is active. All user actions are captured with user identity, timestamp, and action details.

### 6. Apply network-level controls

On Retool Cloud Business+, enable IP allowlisting in Settings → Security to restrict access to known office or VPN IP ranges. For self-hosted deployments, place Retool behind your VPN so it is not publicly accessible, configure firewall rules to restrict the Retool server's network access to only required databases and APIs, and ensure all traffic uses HTTPS via a reverse proxy (nginx with Let's Encrypt or your internal certificate authority).

```
// Self-hosted: Key environment variables for security
// In your docker-compose.yml or .env:

// ENCRYPTION_KEY=<32-char random string>  ← REQUIRED for credential encryption
// COOKIE_INSECURE=false                   ← Enforce HTTPS cookies
// DISABLE_USER_PASS_LOGIN=true            ← Force SSO (after configuring)
// ALLOWED_ORIGINS=https://your-retool.company.com
// JWT_SECRET=<strong random string>

// For Kubernetes:
// Mount ENCRYPTION_KEY as a Kubernetes Secret
// Never put it in ConfigMap (unencrypted)
```

**Expected result:** Retool is only accessible from approved networks. All traffic is encrypted in transit.

## Complete code example

File: `Security Audit Checklist (JS Query: runSecurityAudit)`

```javascript
// Run this JS Query periodically to surface obvious security issues
// It checks the current app context for common security gaps

const issues = [];
const warnings = [];

// Check 1: Is the current user an Admin who should be? 
// (Use this in an admin-only app to verify access control works)
if (!current_user.groups.includes('admin')) {
  issues.push('ERROR: Non-admin user accessed admin app: ' + current_user.email);
}

// Check 2: Are we in production environment?
const env = retoolContext.environment;
console.log('Current environment:', env);

// Check 3: Verify required config vars are set
const requiredVars = ['STRIPE_SECRET_KEY', 'SENDGRID_API_KEY', 'INTERNAL_API_TOKEN'];
for (const varName of requiredVars) {
  if (!retoolContext.configVars[varName]) {
    issues.push(`CONFIG VAR NOT SET: ${varName}`);
  }
}

// Check 4: Log access for audit trail
const accessLog = {
  user: current_user.email,
  groups: current_user.groups,
  environment: env,
  timestamp: new Date().toISOString(),
  appName: 'Admin Dashboard'
};
console.log('Access log:', JSON.stringify(accessLog));

// Report issues
if (issues.length > 0) {
  console.error('Security issues found:', issues);
  utils.showNotification({
    title: `${issues.length} security issue(s) found`,
    description: issues[0],
    notificationType: 'error',
    duration: 8000
  });
}

return { issues, warnings, accessLog, checkedAt: new Date().toISOString() };
```

## Common mistakes

- **Making internal tools accessible on the public internet without authentication** — undefined Fix: Place self-hosted Retool behind a VPN or enable IP allowlisting on Retool Cloud Business+. Internal tools should only be accessible from your corporate network or VPN.
- **Granting Editor access to all team members by default** — undefined Fix: Apply least privilege — give Viewer access to anyone who only needs to run apps. Editor access should only go to people actively building apps.
- **Enforcing SSO before fully testing the configuration** — undefined Fix: Test SSO with one user before enabling 'Enforce SSO'. If the configuration is broken and you enforce it, all users get locked out. Keep an Admin break-glass account with a method to bypass SSO.
- **Relying entirely on UI-side checks (Hidden property) for security** — undefined Fix: Hidden/Disabled properties are UX, not security — they can be bypassed. Enforce permissions in JS Queries as well, checking current_user.groups before executing sensitive operations.

## Best practices

- Enable SSO with MFA enforcement through your identity provider — this is the single highest-impact security improvement for Retool.
- Apply least-privilege permissions: most users should be Viewers, not Editors or Admins.
- Never store API keys or passwords in query bodies, JS Queries, or component properties — use Configuration Variables marked as secret.
- Audit the Admin group monthly — it should contain only the people who genuinely need full org management access.
- For self-hosted deployments, store the ENCRYPTION_KEY in a secrets manager (AWS Secrets Manager, HashiCorp Vault) — never in a config file committed to version control.
- Enable audit logging (Business+) and review it weekly for anomalies.
- Use IP allowlisting or VPN placement to ensure Retool is not accessible from the public internet unless it serves public-facing users.

## Frequently asked questions

### Is Retool Cloud compliant with SOC 2, HIPAA, or GDPR?

Retool Cloud is SOC 2 Type II certified. HIPAA and GDPR compliance is available on Enterprise plans with a signed Business Associate Agreement (BAA) for HIPAA. Self-hosted deployments give you full control over data residency for GDPR compliance. Check Retool's Trust Center at trust.retool.com for the current compliance documentation.

### Can end users see the API keys stored in Retool configuration variables?

No. Secret configuration variables are write-only after creation — their values are never displayed in any Retool UI, not even to Admins. Non-secret configuration variables display their values in Settings to Admins. API keys should always be marked as secret when created.

### What is the fastest way to revoke a compromised user's access in Retool?

In Settings → Users, find the user and click 'Remove user' or 'Deactivate'. For SSO users, disabling the account in your identity provider also revokes Retool access on the next session check (typically within minutes to an hour depending on session timeout settings). Immediately rotate any API keys the user had access to as a precaution.

---

Source: https://www.rapidevelopers.com/retool-tutorial/how-to-secure-retool-applications
© RapidDev — https://www.rapidevelopers.com/retool-tutorial/how-to-secure-retool-applications