HedgeDoc note servers need session and reverse-proxy scope checks

HedgeDoc is a collaborative Markdown editor. Its notes can contain meeting records, design decisions, incident timelines, and links to internal systems. A public note may be an intentional share, but an exposed editor or statistics endpoint can reveal more about a deployment than the author intended.

What ZoomEye returned

On 2026-11-03T04:15:43Z, a count-only query with page=1, pagesize=1, and sub_type=all returned 3,610 total matches for title="HedgeDoc". The same run returned 0 for app="HedgeDoc". The title result is the useful discovery signal in this batch, while the zero app result shows that an application fingerprint with this exact label did not appear in the selected scope.

A title match does not prove that a note is readable. The page may be a login screen, a public landing page, a documentation site, or a custom front end. It may also be an older HedgeDoc or CodiMD deployment whose branding differs. Validate the product and the access model before saying anything about note exposure.

Review note visibility

HedgeDoc's configuration documentation covers local accounts, OAuth2, SAML, note visibility, free URL creation, forbidden note IDs, and web security settings. Determine whether anonymous note creation is enabled, whether notes default to private or public, and whether a user can change visibility after creation.

Review shared links and revision history. A read-only link can still expose sensitive content, and an edit link can allow an attacker to change or delete a note. Test whether an expired session loses access and whether a link can be forwarded to an external recipient.

Free URLs create a usability and security tradeoff. A short or guessable note ID can be enumerated. A deployment that allows anonymous free URLs should not store sensitive material in them. Use a policy that matches the service's intended audience and audit new public notes where the product supports it.

Harden the deployment edge

The reverse-proxy guide recommends binding HedgeDoc to a private host or socket and letting the proxy handle HTTPS. Set the public domain and secure protocol flags correctly so cookies and generated URLs use HTTPS. Restrict /status and /metrics if they expose operational details beyond the intended monitoring network.

Keep the database and upload directory off the public path. Use a dedicated service account with access only to the data it needs. Review the uploads directory permissions, because the container can change permissions on startup. A web server that can read every file in the data directory creates a second exposure path.

If OAuth2 or SAML is configured, check the client secret, callback URL, and account mapping. A local account path that remains enabled can bypass an identity-provider policy. Test logout at both the provider and the application. A provider logout that leaves a local session active can surprise users.

Keep a current inventory

Resolve title matches to the organization's domains and certificates. Record the version, authentication methods, public-note policy, and proxy URL. For owned instances, inspect settings through an administrator account. For unknown instances, do not enumerate notes or attempt access.

Monitor new title matches and changes in public-note policy. Compare the external title with an internal deployment inventory. A branded instance can disappear from the query after a proxy change while remaining reachable. A configuration-management source is therefore more reliable for maintenance than a search engine.

The 3,610 title matches are a candidate population, not a count of exposed documents. HedgeDoc's value is collaboration, so the practical review starts with who can create a note, who can read it, and what the reverse proxy exposes. The search count only tells the team where to begin.

References

• HedgeDoc, Configuration
• HedgeDoc, Using a reverse proxy
• HedgeDoc, Production ready