TL;DR
Retool connects directly to your databases, so security is critical. Use database users with minimal permissions, enable SSO for team authentication, configure granular app permissions, and enable audit logging. For sensitive data, consider self-hosted Retool. Never give Retool admin database access unless absolutely necessary.
Understanding Retool Security
Retool is powerful because it connects directly to your data sources:
- Direct database access: Queries run against your actual databases
- API connections: Can call your internal APIs
- Resource permissions: Control who can use which connections
- Deployment options: Cloud or self-hosted
Database Connection Security
This is the most critical area for Retool security:
Create Dedicated Database Users
- Don't use admin credentials for Retool connections
- Create specific users with limited permissions
- Grant only SELECT, INSERT, UPDATE, DELETE as needed
- Never grant DROP, CREATE, or ALTER permissions
Critical: If Retool has admin database access, a bug in your app or a malicious user could delete or corrupt your entire database. Always use least-privilege access.
Connection Configuration
- Enable SSL/TLS for all database connections
- Use environment variables for credentials
- Consider IP allowlisting for database access
- Regularly rotate database credentials
User Permissions
Control who can access what in Retool:
Permission Levels
- Admin: Full access, use sparingly
- Developer: Can build and edit apps
- User: Can only use apps they're granted access to
App-Level Permissions
- Restrict sensitive apps to specific groups
- Use viewer-only access when editing isn't needed
- Review permissions regularly
Authentication
Enable SSO
- Use SSO (SAML, OIDC) for enterprise authentication
- Enforce MFA through your identity provider
- Automatic user provisioning and deprovisioning
Session Security
- Configure appropriate session timeouts
- Enforce re-authentication for sensitive actions
Query Security
How you write queries affects security:
Parameterized Queries
- Always use prepared statements
- Never concatenate user input into SQL
- Use Retool's built-in parameterization
Data Filtering
- Filter data by user/team in queries
- Don't rely solely on UI hiding for security
- Assume users can see any data the query returns
Best practice: If a user shouldn't see certain data, don't include it in the query results. UI-level hiding is not security.
Audit and Monitoring
- Enable audit logging
- Monitor for unusual query patterns
- Review access logs regularly
- Set up alerts for sensitive operations
Self-Hosted vs Cloud
When to Self-Host
- Highly sensitive or regulated data
- Strict data residency requirements
- Need for network isolation
- Compliance requirements (HIPAA, etc.)
Cloud Security
- SOC 2 Type 2 certified
- Encrypted at rest and in transit
- Regular security audits
Is Retool secure for sensitive internal data?
Yes, when properly configured. Retool is SOC 2 Type 2 certified and offers self-hosted deployment. Security depends on your configuration: database connection security, user permissions, and audit logging. Don't give tools more database access than needed.
How do I secure database connections in Retool?
Use read-only database users when possible. Create specific database users for Retool with minimal permissions. Enable SSL for database connections. Consider using Retool's environment variables for credentials rather than storing them in queries.
Can Retool users access data they shouldn't see?
This depends on your configuration. Set up proper user groups and permissions. Use Retool's permission system to control who can view and edit apps. Most importantly, ensure your database queries filter data appropriately for each user.
Should I use cloud or self-hosted Retool?
Cloud is fine for most use cases with SOC 2 certification. Self-hosted is recommended for highly sensitive data, strict compliance requirements, or when you need data to stay within your network.