Wiki.js deployments often sit behind a custom domain and a title chosen by the organization. The application fingerprint can miss instances while a title search finds many pages that mention the product. A useful review starts with discovery confidence, then moves to the authentication and page-permission model.
A bounded ZoomEye SDK probe on 2026-11-12 between 00:49:21 and 00:49:25 UTC used sub_type=all, page 1, and a page size of one. The application query app="Wiki.js" returned 1. The title query title="Wiki.js" returned 11,979, and http.body="Wiki.js" returned 827,833. The title result is a candidate inventory. The body result is too broad for a deployment count, and the single application match shows that fingerprint coverage alone is not sufficient.
Determine the product generation
Wiki.js 2.x and 3.x have different administration and API documentation. The current public documentation set includes a 3.x site and a 2.x archive. Check the installed version before applying an auth or API procedure. A team that follows a 3.x REST API instruction on a 2.x deployment will waste time and may misread the permission model.
Review the authentication modules in use. Local passwords may be disabled in favor of SSO, but the local login path and recovery process still need an owner. Check group membership, page rules, and API token scopes. The product documentation describes fine-grained permissions and recommends a dedicated group for API access.
Enable API access only when the deployment needs it. An API token should carry the smallest set of permissions required by its automation. Treat the token as an identity: record who created it, which group it belongs to, which pages or actions it can reach, and when it will be rotated.
Review the public and private page boundary
A wiki combines public documentation, authenticated pages, and administrative settings. Test a guest request and a low-privilege user request against a page that should not be visible. Check whether search results, navigation, sitemap entries, and asset paths follow the same rules as the page view. An image or attachment URL can bypass a page-level expectation if it is served from a public path.
Review user registration and invitations. An open registration flow can create an account that enters a default group with more access than the owner realizes. Check the default group for every authentication module. If SSO supplies roles or groups, verify how a missing or unknown group is handled.
The admin area should be reachable only by the accounts that need it. Check the reverse proxy, authentication policy, and session lifetime. A custom domain does not make an exposed login page safer. Security headers and TLS settings matter, but they do not replace page and group authorization.
Build an owner-confirmed wiki list
Use the title candidates to find likely sites, then confirm the product and version from an authorized request or the owner's records. Deduplicate custom domains and staging hosts. The 827,833 body matches should be retained only as a recall signal. A page that mentions Wiki.js in a tutorial is not a Wiki.js deployment.
For each owned deployment, record the version, auth modules, default group, API status, page rules, storage backend, backup owner, and update process. Check whether public search is enabled and whether it indexes pages outside the intended audience. Review a recent authentication change and confirm that a revoked user cannot still read a cached page.
ZoomEye helps find candidate wikis that are missing from a service catalogue. The security answer depends on the permission model and the deployment's public routes. A title count can start an inventory; it cannot establish that the wiki's private pages are actually private.