OpenProject API Tokens Connect Public Enumeration to Project Authorization

OpenProject API Tokens Connect Public Enumeration to Project Authorization OpenProject exposes a project-management interface and an API v3. Its API documentation supports session authentication, API tokens, and OAuth 2.0, including external authorization servers. The project also exposes non-confidential metadata and discovery endpoints. That combination is useful for automation, but it means a public host may reveal product and deployment details before an API request reaches project data. The ZoomEye count-only snapshot on November 8, 2026 used sub_type=all, page 1, and page size 1. app="OpenProject" returned 11,684. title="OpenProject" returned 12,442. http.body="OpenProject" returned 45,326. The app and title counts are close and consistent with a recognizable product surface. The body count is larger and may include documentation, project pages, and references. None of the counts proves that an anonymous user can read work packages. OpenProject's API introduction says that many resources can be accessed without authentication depending on the instance settings. Otherwise unauthenticated clients receive the permissions of the anonymous user. That wording is important. A successful public API response may be an intentional anonymous permission, a configuration mistake, or a resource that the API exposes as metadata. The team should verify the instance's anonymous role and the visibility of projects before classifying the response. API tokens are the next layer. OpenProject documents bearer-token and Basic-auth forms, plus OAuth flows. Each token belongs to a user and inherits that user's permissions in project membership and roles. A token generated for a script can become an overbroad personal credential if the user changes teams. Inventory token owner, creation date, last use, purpose, and the projects the owner can access. Rotate after staff changes and revoke unused tokens. The /.well-known/openproject-metadata endpoint is described as accessible without authentication and exposing non-confidential installation metadata. That is a useful discovery aid, not a vulnerability by itself. Review what the endpoint returns and whether the disclosed installation UUID or version information helps an attacker correlate other data. Keep the information in the asset inventory and avoid adding secrets to custom metadata. OAuth and external identity add lifecycle paths. If OpenProject trusts an external authorization server, confirm the issuer, audience, key rotation, and user mapping. Test deprovisioning from the identity provider through to project access. A disabled login that leaves a personal API token active is a common gap. The API token registry should be reconciled with the identity provider's active-user list. The public surface review should compare the app and title candidates with DNS and internal project inventory. Confirm the hostname, TLS certificate, and application owner. Check whether CORS is enabled for the API and, if so, which origins are allowed. Review the API documentation setting and disable it where the organization does not need a public interactive reference. ZoomEye helps map the candidate population and shows the difference between product fingerprint, title, and page content. The internal review determines whether the public metadata is paired with an anonymous role that sees more than intended. OpenProject can be safely public when the anonymous permissions are explicit and the token lifecycle is controlled. It becomes risky when external discovery is the only place the team learns that a project endpoint is reachable. Query evidence Collection: 2026-11-08 00:44 UTC, ZoomEye SDK, sub_type=all, page 1, page size 1. app="OpenProject": 11,684. title="OpenProject": 12,442. http.body="OpenProject": 45,326. References OpenProject API introduction OpenProject API documentation OpenProject API and webhooks administration OpenProject access tokens ZoomEye app query ZoomEye title query