Appsmith public apps need a data-source review
Appsmith lets teams build internal applications on top of databases and APIs. The platform encrypts stored data-source credentials and can add granular access controls, which is useful. It also supports sharing an app with users who may not have an editor account. A public app can still run prepared queries against a backend, so the relevant security boundary is what the app exposes, not whether the login screen looks familiar.
The official documentation describes login methods including form-based, OAuth and SAML, and its self-hosting guidance recommends disabling open signups and using federated authentication where possible. Audit logs note that anonymous public users can view a page. Those two facts belong in the same review: the authentication posture of the instance and the exact set of operations available to an anonymous viewer.
A product-surface measurement
On 2026-10-29 at 17:40 UTC, a ZoomEye sub_type=all query with page_size=1 returned 35129 matches for:
title="Appsmith" || http.body="Appsmith"
The query inventories pages that identify Appsmith in their title or body. It does not prove that an app is public, that anonymous users can execute a data-source query or that a deployment is vulnerable. An owner should correlate the match set with approved Appsmith instances and then inspect the running authorization policy.
Separate identity from data authority
Inventory the accounts that can edit applications, edit data sources, deploy a version and read audit logs. Then inventory the applications that allow public or guest access. For each public app, list the queries it can execute and the backend role used by its data source. A dashboard with a read-only service account is different from a form that can update a customer record. The instance login method does not answer that question.
If form login is enabled, require email verification and close open signups. Use SSO or OIDC where the organization can support it, and map identity-provider groups to the smallest useful instance roles. Review Granular Access Control policies for app, page, query and data-source resources if the edition supports them. Remove orphaned users and service accounts that were created for an old integration.
Do not place database administrator credentials in an application data source. Use a dedicated account with table and operation scope that matches the app's purpose. Review query parameters and server-side execution so that a public viewer cannot change the target or inject arbitrary SQL. The platform's credential encryption protects storage, but the app can still intentionally execute the query it was designed to run.
Test anonymous behavior
In a staging instance, publish a non-sensitive app with a read-only query. Open it in a private browser session and confirm which pages, queries and exports are reachable. Attempt a write or an administrative endpoint and verify that it is rejected. Check the audit log for the anonymous page view and for the query-related events your edition records. Then revoke the public access and confirm that the cached browser session and any API path also stop working.
Monitor public-app changes, new data-source creation, role changes and anonymous traffic. Alert when a public app uses a data source with write access or when an instance setting changes from federated login to open form registration. Keep the app inventory tied to an owner. An internal tool that is public by accident is easier to find when the platform, network and data-source inventories agree.
Appsmith can be a useful internal application layer without becoming a public database proxy. The control is to know which identity can run which query and to test that boundary as a user who has no editor role.
Top comments (0)