CiviCRM runs alongside a content management system and stores contacts, memberships, contributions, event registrations, and relationship data. A count-only ZoomEye query found 0 application matches and 444 title matches on 2026-11-04. The title population is a useful review queue for organizations that rely on CiviCRM for fundraising or member services.

How the measurement was taken

The probes used app="CiviCRM" and title="CiviCRM" with sub_type=all, page 1, and pagesize 1 at 07:49 Asia/Shanghai. The reported counts were 0 and 444. The title match can appear on a login page, a public directory powered by CiviCRM, a help page, or a site that merely mentions the product. The application count did not identify a product fingerprint for the exact value used.

CiviCRM's API documentation describes several authentication forms, including API keys, JSON Web Tokens, and Basic credentials through AuthX. Traditional REST key pairs remain supported on specific endpoints and versions. That history matters because an older integration may use a different authentication path from a newer application.

Review the CMS and CRM together

The CMS session is often part of the CiviCRM login path. A WordPress, Drupal, or Joomla account can therefore become a pathway into constituent records. Review the CMS roles, the CiviCRM permissions, and the mapping between them. A user who should only edit a public page must not inherit API access or contact-export authority through a shared role.

Inventory API keys and identify the person or service that owns each one. Test whether a key can read a contact that the corresponding user should not see. Review the site key separately; it is shared by the deployment and should not be treated as a user secret. If AuthX is enabled, confirm which credential types and headers are accepted. Disable password authentication for API paths when the deployment does not require it.

Protect constituent records

Contact records may include postal addresses, donation history, membership status, communication preferences, and notes from case workers. An export can be more damaging than a single record view. Restrict bulk export, log the number of records returned, and require a documented business reason for large queries.

Apply the same retention and access rules to CiviCRM extensions and custom fields. A custom field can hold sensitive data that the default permission set does not understand. Review scheduled jobs and webhooks because both can move records to another system. Keep the CMS, database, and backup credentials in a secret manager rather than a web root configuration file.

Test the public surface

From outside the organization, confirm that the public pages expose only the intended forms and directories. Try an API request without a credential and with an invalid credential. Confirm the response is a denial and not a redirect to a login page that hides a successful backend call. Check that error handling does not reveal the site key, API key, database name, or extension version.

The 444 title matches should be reconciled with known domains and certificates. A public-facing chapter site may be an intentional CiviCRM deployment. A staging or administrator endpoint should not be. The count is the beginning of that ownership and configuration check.

References

[1] CiviCRM APIv3 REST documentation

[2] CiviCRM APIv4 REST documentation

[3] CiviCRM AuthX framework

[4] ZoomEye result for title="CiviCRM"