Document-signing services mix several kinds of access in one web application. Staff members build templates, API clients submit document requests, signers open unique links, and administrators manage users and account settings. Each path can have a different credential. An inventory count is useful only after the team maps those paths to the controls protecting them.

Two observations

On 2026-10-30, ZoomEye count-only queries used sub_type=all, page 1, and page size 1. app="DocuSeal" returned 2,269 matches. title="DocuSeal" returned 2,242 matches. Neither query establishes whether a host is unauthenticated or vulnerable. The two numbers also should not be subtracted to estimate a population, because the fingerprints can overlap and each query applies different matching logic.

The similar counts suggest that DocuSeal has a recognizable application or page title in the observed data. That makes it a reasonable product to include in an exposure inventory. It does not replace direct inspection of the staff login, signing route, API, and download behavior.

Separate the participants

DocuSeal's documentation distinguishes account roles such as editor and administrator. The project's security page describes SAML single sign-on and an option to enforce API-token authorization for file downloads. These are different controls from the signing link that a recipient uses to complete a document.

A signing link is often designed to be usable without a staff account. That can be correct for the workflow, but the link still needs a scope: which submission, which signer, which fields, and how long it remains usable. A public route should not reveal unrelated documents or expose account administration.

Staff roles need the same review. An editor who can manage documents may not need account settings or user administration. API tokens should belong to a defined integration and have a retirement path. A token embedded in a browser-side application is not a server secret.

Inspect the deployment paths

Start with the listeners. Confirm whether the web UI, API, and any embedded signing flow are exposed through the same hostname and reverse proxy. Inspect redirects and direct ports. A host that redirects a browser to a login page may still serve an API path that behaves differently.

Test a document download with and without the expected authorization. Use a disposable submission and a test user. Do not inspect a real signer's document. Record the response status, content type, and whether the token scope was enforced. If the application supports enforced token authorization for downloads, verify that the setting is active in the target deployment and that it does not break an approved integration.

Review administrator and editor accounts for unused access. For self-hosted deployments, include the database and storage paths. A document service is not only the web process; backup files and object storage may contain the same PDFs with weaker access controls.

Use the count as a prompt

An external count can show where a product family appears at internet scale and help prioritize an asset inventory. The next question is local: which DocuSeal instances belong to us, which signing links are intentionally public, which accounts have administrative rights, and what evidence shows that a download token was required?

Record the exact query, scope, time, and count with the evidence. Then attach the internal answers to the same asset. A title match alone cannot answer whether the service is configured correctly.

References