Lightdash tokens can inherit both project access and warehouse reach
Lightdash connects a semantic analytics layer to a data warehouse. Users explore metrics and dashboards through the Lightdash service, while the service holds or references credentials that can query the warehouse. A project access review therefore has two layers: who can use Lightdash, and what the underlying data connection is allowed to read.
A count-only ZoomEye query on 2026-11-02 returned 3,305 assets for app="Lightdash". The query used sub_type=all, page 1, and page size 1. The app fingerprint identifies matching product assets in the scan corpus. It does not establish that a project is publicly accessible or that the service is vulnerable.
The ZoomEye query is an inventory signal. Confirm ownership through DNS, certificates, cloud records, and deployment metadata before testing a host.
Understand the token subject
Lightdash supports personal access tokens for API access. A token represents the authority of its user, including the projects that user can reach. The documentation and project permission guidance matter because a token created by an administrator can be far more powerful than a token created by a project viewer.
Inventory tokens by owning user, creation date, purpose, and project scope where available. Do not put an administrator's token into a shared reporting job. Create a dedicated identity with only the projects and operations the job needs. Remove tokens when the owner leaves or the integration is retired.
Tokens are bearer credentials. Store them in a secret manager, not in dashboard configuration, source code, browser local storage, or a screenshot. Client-side applications should not receive a token that can query every project. If a browser needs data, access should go through an application backend that enforces authorization.
Review project access
Check organization members and project access separately. A user may be an organization member without access to every project. Project-level permissions should map to a small number of roles that are easy to audit. Review project administrators, editors, viewers, and any custom roles that exist in the deployment.
Shared spaces, dashboards, and charts are not the only data paths. A viewer may be able to use Explore or the API to issue a query beyond a saved chart. Test with a low-privilege account against projects the user should not see. Check saved SQL, custom dimensions, filters, and parameters that can alter the query scope.
Lightdash permissions are layered. A project-level role may be additive with an organization role, so a broad organization grant can defeat a narrow project grant. Validate the effective access rather than relying on one settings page. Repeat the test after a role or custom permission change.
Separate the warehouse credential
The data source connection often holds credentials to the warehouse. Use a read-only database user for interactive analytics. Restrict schemas, tables, rows, and functions to the minimum the project needs. If multiple projects use the same warehouse, do not give one shared credential access to every dataset when separate roles are possible.
Store the connection secret in the Lightdash deployment's secret management path. Avoid a personal warehouse token tied to an employee account. A service identity should have an owner, rotation procedure, and a way to revoke access without breaking unrelated projects.
Check network egress. The Lightdash service may need to reach a warehouse endpoint, but it should not also be able to reach arbitrary internal administration services. Use a restricted egress policy and TLS verification. If a proxy is required, ensure it does not allow a user-controlled URL to become a new request path.
Validate the public deployment
For each observed host, record the hostname, certificate, IP address, app evidence, first-seen time, and organization. Determine whether it is a production instance, a demo, or a documentation page. Check TLS and authentication configuration through authorized observation. Do not attempt to use guessed tokens.
Compare the public hostname with the configured URL and callback URLs. A stale alternate hostname may bypass a newer access policy. Review reverse-proxy headers and trusted proxies so a client cannot set an administrative identity or an internal project header.
Forward authorization, token creation, project changes, and failed query events to an independent logging system. Alert on new tokens with administrative access and on queries from an unusual service identity. Keep the query and count history from ZoomEye as an inventory signal, not as evidence of data exposure.
Lightdash is useful because it makes warehouse data easier to consume. That convenience increases the value of the identities that can query the warehouse. Review tokens, project roles, and data-source credentials together, then prove the least-privilege result with an actual query test.
Top comments (0)