Retool Penetration Testing

A resource is Retool’s shared connection to a database or API, and every query passes through the credentials attached to it, not the browser. What that resource’s permission level and credential scope actually allow, rather than what the app’s interface offers, is what a query can reach.

The resource decides what a query can reach, not the app built on top of it

Retool’s permission system runs on two layers: groups that grant Use, Edit or Own access to apps, resources, workflows and agents, and, on higher-tier plans, resource permissions that can be set separately for each environment a resource is configured in. Retool’s own documentation is explicit that there is no default resource permission across environments: production and staging must each be granted independently, and a new environment added to a resource inherits nothing from the environments already configured on it. We test whether that separation actually holds, or whether a group with staging Use access on one resource turns out to have Edit or Own on production without anyone deciding that on purpose.

Every query an app runs is proxied through the resource it is attached to, and the resource’s credentials, not the app, decide what the database or API will accept. Retool’s own security documentation confirms that connecting an app to your own database means Retool proxies requests and applies the credentials server-side rather than letting the browser connect directly. SQL queries take {{ }} embedded expressions from components and other queries, and Retool converts them into prepared statements by default specifically to stop that input being used to inject SQL, though some database integrations let a resource administrator turn that conversion off. We test which queries take user-controlled input, whether prepared statements are still in force where it matters, and what a query can actually do once it runs, since that ceiling is set by the resource credential, not by what the app’s interface offers.

Filtering a table or an action by current_user, whether that is their email, their assigned permission groups or a custom attribute, only restricts what a user sees if every query touching that data applies the filter consistently, and current_user is not available at all in a public app that does not require sign-in. The same resource a form or table queries can also be reached from a scheduled or webhook-triggered workflow running unattended, and from a self-hosted deployment where your own infrastructure, rather than Retool’s, runs the containers that hold those credentials. We test the client’s apps, workflows, resources and permission configuration, on Retool Cloud or self-hosted, and never Retool’s own platform.