DEV Community

SorrelThorncroft
SorrelThorncroft

Posted on

Wiki.js Exposure: Distinguish Public Pages from Administration

#wikijs #zoomeye #knowledgebasesecurity

Wiki.js Exposure: Distinguish Public Pages from Administration

A wiki may be designed to publish documentation to the Internet. The security question is which pages, accounts, API keys, and administrative actions share that public hostname.

Public content is not the same as public administration

Wiki.js supports local authentication and external strategies such as OIDC, OAuth2, SAML, and passkeys. Its permission model includes fine-grained rights, including the ability to use scripts. The audit log records user actions and can be exported.

Those features need a clear boundary. A public page can be intentional while the authoring, script, group, and API settings remain restricted. Review anonymous access, group mapping, API keys, and the administrators who can change authentication configuration.

Why proxy trust matters

The Wiki.js authentication and audit documentation says deployments behind a reverse proxy should enable trust for X-Forwarded-* headers. The wiki then records the visitor's address instead of the proxy's. If that setting is wrong, rate limits, audit records, and access decisions based on client context may all be misleading.

Reverse-proxy trust must be narrow. Configure the application to accept forwarded headers only from known proxy addresses. Do not let arbitrary clients set the header on a direct connection. Test both the direct backend and the public proxy path.

Interpret the title count

The selected probe used title="Wiki.js" with sub_type=all, page 1, and page size 1. It returned 11,956 matches. A title may identify a public wiki, a login page, a test instance, or an unrelated page. It does not reveal whether anonymous editing or script permissions are enabled.

For each owned match, compare the hostname with the content owner and the authentication policy. Fetch the page as an unauthenticated visitor and then as a low-privilege user. Check whether the audit log records the correct source address. Confirm that write:scripts, API-key creation, and auth-strategy changes are limited to trusted administrators.

Keep knowledge useful and bounded

Rotate API keys, remove unused external providers, and review group claims after an identity-provider migration. Export audit logs to a system with independent retention. Test a deleted user and a user removed from an IdP group. The wiki should remove access according to the documented mapping.

A public wiki is often a business asset. The safe configuration makes the public, authoring, and administrative surfaces visibly different and keeps the evidence needed to investigate a change.

ZoomEye count-only probe: title="Wiki.js" with sub_type=all, page 1, and page size 1.

The probe ran at 2026-11-02 19:38:57 UTC and returned 11,956 matching records. The result describes a Wiki.js fingerprint match, not a confirmed vulnerable or compromised installation.

Exact search link: https://www.zoomeye.ai/searchResult?q=dGl0bGU9Ildpa2kuanMi

References

Top comments (0)