OpenProject combines project management, work packages, repositories, meetings, and integrations in one application. Its API supports personal access tokens, OAuth 2.0 flows, and OIDC-issued bearer tokens. A token may look like a single secret, but the access it provides depends on the user, the project membership, the assigned role, and the permissions attached to that role.
The OpenProject API documentation states that API links are filtered by the authenticated user's permissions. A work package response may include update or delete links only when the user is allowed to perform those actions. That behavior is useful, but it also means a security review cannot be limited to the presence of an API key. The reviewer must inspect the underlying membership and role.
Personal tokens and OAuth have different lifecycles
A personal API token is created from the user's account settings. The system administrator can control whether users are allowed to create personal API tokens. A token can make requests as the user, so it inherits that user's current project memberships and permissions. If the user is added to a new project after the token is created, the token may gain the new access without any token-specific change.
OAuth applications support authorization-code and client-credentials modes. An OAuth access token may expire after a short period, depending on the configuration, and can be refreshed. That is a different lifecycle from a personal token. The application registration, redirect URI, client secret, and consent record are part of the security boundary.
An OIDC bearer token from a configured identity provider can also authenticate API requests. In that model, the identity provider's issuer, audience, signature, and claim mapping must be correct. A token that is valid at the identity provider but intended for another application should not be accepted by OpenProject.
API responses are a useful diagnostic
Use the API's permission-filtered links to test a user's effective access. For a work package, compare the response for an administrator, a project manager, a regular member, and a user with no membership. Confirm that the update and delete links appear only where the role permits them. Test a project the user should not see and verify that the API does not disclose metadata through list, search, or activity endpoints.
Test administrative endpoints separately. A project role may allow work-package changes without allowing user management, custom fields, authentication settings, or API token policy changes. The review should cover both project data and instance-wide configuration.
Do not use only the UI to judge the API. Some actions are hidden by the frontend while the backend still enforces permission. The reverse can also happen after a configuration change. Validate with an API client and a non-production account.
Protect the token issuance path
The token creation page is an attractive target. Require strong authentication for administrators and privileged project members. Review session timeout, password policy, MFA, and the identity-provider configuration. A personal token created from a compromised session can survive after the session is closed unless it is revoked.
OAuth client secrets should be stored in a secret manager and rotated after exposure. Confirm that the redirect URI is exact and not a wildcard that lets an attacker receive an authorization code. For client-credentials applications, give the application its own identity and the minimum role it needs.
Audit token creation and revocation. Record the token type, owner, application, creation time, last use where available, and the projects the owner can access. Do not log the token value.
Measurement and interpretation
ZoomEye's application fingerprint can help find systems that present as OpenProject. It is an inventory lead for owned domains, not proof that a token or API endpoint is exposed.
Measurement
On 2026-11-11, a ZoomEye count query with dork app="OpenProject", sub_type=all, page 1, and page size 1 returned 11,689 matching assets. The deterministic search link is the OpenProject ZoomEye query. The total describes matching product assets, not confirmed vulnerable installations or valid credentials.
Compare the result with the organization's domain and cloud inventories before taking action. A matching host may be a public demonstration, an internal service reachable through a proxy, or a system owned by another organization.
Response when a token is exposed
Revoke the token, review the owner's role bindings, and inspect API activity for the token's lifetime. Check work-package changes, project membership changes, attachment downloads, and administrative actions. If the token could access a repository or external integration, review that system's logs as well.
If the owner is a shared account, rotate the account's credentials and replace the integration with a dedicated service identity. If the token was created through OAuth, revoke the application grant and rotate the client secret when compromise is plausible.
After containment, reduce the owner's role if it was broader than necessary. Remove project memberships that are no longer needed and review whether personal API tokens should be enabled for that role population. The goal is to make the next token's maximum impact smaller.
OpenProject's authorization model is project-centric. The effective permission and the token lifecycle should be reviewed together.