A CKAN portal is a public interface to a catalog of datasets, organizations and resources. That interface can serve open data, but it can also reveal how an organization names internal collections, who administers them, which files are private, and what API access exists. A product search gives an inventory starting point. The security question is whether the visible catalog matches the intended publication boundary.
On 2026-10-31, a count-only ZoomEye query with sub_type=all, page 1 and page size 1 returned 1,488 matches for app="CKAN" and 1,666 for title="CKAN". The queries ran at 23:44:26 UTC and 23:44:29 UTC. These are matching asset counts, not counts of vulnerable sites. Title matching can include documentation, test pages and other uses of the name. The application count gives a second view of the same broad product family.
CKAN's authorization model is organization-aware. An organization administrator controls that organization's members and datasets. A dataset may be public or private, and private datasets are not returned in searches unless the user or the API key has permission to see them. The portal therefore has at least three review planes: what an anonymous visitor can browse, what an authenticated dataset collaborator can discover, and what an API token can do beyond the browser interface.
The API deserves its own inventory. CKAN exposes dataset, resource and organization operations through an API, and API tokens can act with the identity and permissions of their owner. A token created for a data pipeline may have broader reach than the application that consumes it. Review token ownership, creation time, unused credentials, revocation and whether the token is stored in a CI system, notebook, public repository or client-side application.
Legacy API behavior should not be used as a substitute for testing the current API. CKAN documentation notes that the legacy search API only returns public datasets regardless of supplied authorization. A team that checks only the legacy endpoint may conclude that private data is protected, while another supported endpoint returns different results for an authorized account. Test each endpoint and permission role that the deployment actually enables.
Resource links add a boundary outside CKAN. A catalog record can point to an object store, an external download service, a preview service or a private repository. The portal may correctly deny a dataset record while a resource URL remains reachable to anyone who knows it. Inventory those links and verify the storage service's authorization separately. A portal search should not be treated as a complete inventory of downloadable files.
A practical workflow starts from the ZoomEye result, confirms the response title or application context, and then records the organization, base URL, CKAN version and visible API endpoints. From there, the owner should test anonymous search, authenticated search with a low-privilege account, organization administration boundaries, token scope and direct resource access. Each test should use a non-destructive read where possible and preserve the expected result before it is compared with observed behavior.
The counts also support change monitoring. A sudden movement in application or title matches may indicate a new deployment wave, a proxy change, a rebrand or a measurement artefact. It does not prove that a private dataset became public. Keep the query, timestamp and index scope with the count, and pair that evidence with an authorization test on the asset itself.
CKAN is designed to publish information. The useful review asks what is published, to whom, through which API and with which backing resource. ZoomEye can find candidate portals at internet scale. The organization still has to verify the data boundary inside each one.