Tolgee is a translation management platform with projects, members, branches, integrations, and several API credential types. An exposed instance can contain product strings, unreleased content, and integration secrets. The security review needs to distinguish a project key from a personal access token.

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

The query is reproducible through the selected ZoomEye search.

Project keys and personal tokens have different scope

Tolgee documentation says a Project API key authorizes access to a single project and can carry selected scopes. A Personal Access Token authorizes the user across resources the user can access, except resources that manage the tokens and other sensitive endpoints.

That difference is important during incident response. A leaked project key should be contained to one project, but it may still permit translation reads and writes for that project. A leaked PAT may reach every project the user can access. Inventory the credential type before estimating impact.

The documentation recommends the X-API-Key header over the ak query parameter because query parameters can be stored in server logs. Audit proxy and application logs for query-string keys, then remove them and rotate any key that appeared in a location with broad access.

Branching does not isolate project keys

Tolgee's branch documentation says project API keys are scoped to the project and work across all branches. Branch protection is a separate control. A key that can edit translations may reach a protected or unreleased branch unless the project's permissions and branch policy prevent it.

Test a project key against the default branch, a feature branch, and a protected branch. Confirm that the server enforces the project role and the branch rules. A key that was intended for a read-only integration should fail a write attempt on every branch.

Review the project member list alongside the keys. A user who left the project may still have a PAT. A project key may be shared by multiple integrations, which makes attribution difficult. Use one credential per integration and label it with an owner.

Sensitive actions need stronger authentication

The Tolgee API documentation says some endpoints require a Super JWT token that needs two-factor authentication and is valid only for a short period. Project API endpoints can use a project key, and non-project endpoints require a PAT or another allowed method.

Do not treat a project key as a general administrative credential. If a workflow needs organization-level access, use the appropriate token and require the stronger authentication path. Review who can generate a PAT and whether MFA is mandatory for those accounts.

Test token regeneration and expiry. A regenerated key should invalidate the old value within the documented behavior. A key with no expiry needs an owner and a periodic review. A key embedded in a public frontend bundle is exposed even if the UI hides it.

A practical review for an owned instance

List every project, member, branch, and integration. For each integration, record whether it uses a project key or a PAT and the exact scopes it needs. Test a read-only translation pull, a write, a branch switch, and a project-management request.

Review the self-hosted deployment's public endpoints and reverse-proxy headers. The product title is not an authorization result. Confirm that unauthenticated requests cannot enumerate projects or download translation bundles through an unprotected content-delivery route.

The 876 title-and-body matches are an inventory signal. They do not reveal which projects are public or which keys are active. For each owned host, compare key type, project scope, branch access, MFA, and integration ownership. Tolgee's key model is useful when the credential type and its effective reach are both visible.

References