Appsmith Penetration Testing

A datasource is Appsmith’s stored connection to a database, API or service, and every query attached to it runs with that connection’s saved credentials, not the credentials of whoever is using the app.

The datasource’s saved credentials decide what a query can reach, not the role that triggered it

Appsmith workspaces run on Granular Access Control, a permission system Appsmith gates behind its Business plan below the instance-wide Organization Administrator role. Every user gets one of a small set of default roles, Workspace Administrator, Developer or App Viewer, or a custom role built on the same model, and each grants a different set of Create, Edit, Delete, View and Execute rights over apps, pages, queries, datasources and environments. Making an app public sits on its own permission, separate from the rest: Appsmith’s own reference confirms a Workspace Developer can create, edit and delete everything inside an app but cannot make it public or export it, so that ability has to be granted, or withheld, deliberately. We map every role and custom role in scope against what its Make Public, Export and per-environment permissions actually allow, rather than assuming the workspace hierarchy matches the org chart.

A datasource is Appsmith’s stored connection to a database, API or other service, and every query attached to it runs with that connection’s saved credentials rather than the credentials of the person using the app. Appsmith’s own security documentation is explicit that the server appends those credentials to the request immediately before it reaches the backend, so they are never sent to the browser, and that an existing secret cannot be viewed again once saved, only replaced. SQL queries take {{ }} values from widgets and other queries, and Appsmith enables prepared statements for every SQL query by default specifically to stop that widget input being used to inject SQL. The setting has to be turned off wherever a query needs a dynamic table name or a dynamic query structure built from a widget’s value, since a prepared statement cannot represent either. We test which queries carry that exception, whether the resulting input is validated some other way, and what the underlying datasource credential can actually do once a query built from user input reaches it.

Logic written into a JS Object runs in the browser, and Appsmith’s own security guidance is direct about what that means: users can open browser developer tools and read it, so a permission check or a hidden feature flag written only in client-side JavaScript is not a control, it is a suggestion. The same guidance warns against holding sensitive values in Appsmith’s storeValue() function, since that data sits in the browser’s local storage and can be inspected the same way. Self-hosted instances add their own configuration layer on top of this: the APPSMITH_ENCRYPTION_PASSWORD and APPSMITH_ENCRYPTION_SALT environment variables protect every stored datasource credential, and APPSMITH_SIGNUP_DISABLED or APPSMITH_SIGNUP_ALLOWED_DOMAINS decide whether an uninvited account can join the instance at all. On Appsmith Cloud those settings are managed for you; self-hosted, they are configuration your own team has to set correctly. We test the client’s JavaScript logic and storage use, and, where self-hosted, the environment configuration actually deployed, rather than treating either platform’s defaults as sufficient on their own.