Chartbrew is a self-hosted reporting platform that connects dashboards to databases, APIs, and analytics services. A Chartbrew instance can hold live credentials for those sources. Its public surface is therefore more than a chart page. It includes team membership, report sharing, client accounts, API keys, and the data connections behind every chart.

On 9 November 2026 at 08:50 Asia/Shanghai, a ZoomEye query using sub_type=all, page 1, and page size 1 returned 115 assets for title="Chartbrew" && http.body="Chartbrew". The title query returned 116, the body query returned 172, and the application fingerprint returned zero. The intersection is a conservative title-based inventory.

The query is reproducible through the selected ZoomEye search.

Public reports are a data boundary

Chartbrew's feature documentation describes client accounts with granular access to specific dashboards. A report can be shared with a client or embedded in another application. The security question is what the public report contains and which query or data source feeds it.

A chart title and a public report do not prove that the underlying database is exposed. They do mean that a viewer can see the chart's data and metadata. Review the report's filters, dimensions, and refresh behavior. A public report may disclose customer names, revenue, account health, or operational metrics even when the source credentials remain server-side.

Separate the team role from the report permission. A user with a limited role should not be able to open every project or change a shared query. Test the actual account, not only the link.

API keys can reach the whole account

Chartbrew's own documentation describes API keys as useful for fetching or creating content from another application. It warns that the token can read and modify data in the Chartbrew account. That is a broad statement and should shape the token inventory.

List every API key and the integration that owns it. Revoke keys that belong to retired scripts or former users. Prefer a separate service identity over a personal account when the integration is shared. Record the key's last use and the data sources it can query.

Do not place an API key in a public dashboard, browser-side JavaScript, or a screenshot. If a key is exposed in a support ticket, regenerate it instead of editing the transcript. The key is a credential even when the UI calls it an integration token.

The refresh endpoint needs authorization

A Chartbrew security advisory describes a missing authorization condition on POST /api/chart/:chart_id/query through a team-level refresh toggle. The reported issue shows why the refresh path needs the same ownership checks as the chart view. A team setting is not a substitute for verifying that the requested chart belongs to the caller and the sharing policy permits the operation.

Review the installed version against the advisory and the project's release notes. Then test the endpoint with an unauthenticated request, a user from another team, a user with read-only access, and a public-report viewer. Record the response and the server-side authorization decision.

Do not test against a production data source. Use a test chart with synthetic data and a separate database account. The goal is to prove the authorization boundary before a real query is executed.

A practical review for an owned instance

Start with the connection inventory. Record every database and API source, its credential owner, the minimum query privilege, and the dashboards that use it. A read-only database account is safer than a writer, but a read-only account can still expose every table the connector is allowed to query.

Then review the report and team model. Check public reports, embedded reports, client accounts, and scheduled exports. Confirm that a public viewer cannot change a query, retrieve the source credential, or enumerate another team's charts.

Finally, test the API key and refresh paths. Use a non-production chart and a separate account. Confirm that the server checks authentication, team membership, chart ownership, and the report's sharing policy. The 115 matches are an inventory signal. They do not show which charts are public or which data sources are connected. The useful follow-up is an owner-by-owner comparison of public sharing, API credentials, and the data behind each report.

References