DEV Community

SorrelThorncroft
SorrelThorncroft

Posted on

changedetection.io API keys and webhooks share authority

changedetection.io API keys and webhooks share authority

changedetection.io monitors web pages and sends notifications when content changes. A self-hosted deployment may watch vendor bulletins, internal dashboards, restock pages, or sensitive public pages. The service's API keys and notification targets are therefore part of an operational control plane, even when the visible title count is tiny.

Observation

At 08:42 on November 4, 2026 (UTC+8), a count-only ZoomEye SDK query with sub_type=all, page 1, and pagesize 1 returned zero application matches for app="changedetection" and three title matches for title="changedetection". The low result limits what can be inferred. The three matches may be demos, documentation, or instances that present a different title. None is confirmed to be a production service.

API and notification authority

The official API documentation says almost all API requests require an API key and that notifications can target services including webhooks. That creates two related permissions. An API key can usually manage watches, while a notification target receives information about changes. A compromised key can add a watch, alter a selector, or redirect an alert. A malicious notification target can receive content that the operator intended to keep internal.

The review should map watches to owners. Each watch should identify the monitored URL, the fields being extracted, the notification destination, the retention period, and the person who can delete it. A watch that includes cookies, authorization headers, or private page content needs stronger storage controls than a public price page.

Test the API boundary from a client that should not have access. Confirm that the server rejects a missing or wrong key, that the rejection does not reveal watch details, and that rate limits do not become a way to enumerate targets. If a reverse proxy provides authentication, verify that it cannot be bypassed through the API port or a direct container address.

Review checklist

Recommended checks include:

  • Inventory API keys and the watches they can modify.
  • Review webhook URLs and secrets, especially external destinations.
  • Confirm that private page content is not written to shared logs.
  • Test notifications with a safe endpoint and verify the payload fields.
  • Check backup retention for watch definitions and captured content.

The ZoomEye count can support monitoring of the public title population. It should not be presented as a vulnerability scan, and three title matches do not mean that only three deployments exist. The article's useful conclusion is that visibility and notification authority sit on the same service. An organization that can find the host but cannot name the watch owner has not completed the review.

Use the search link to repeat the exact title observation at a later time. Record the query time and scope because title counts change as sites are indexed, moved, or renamed. Pair that external observation with internal evidence from the service's API and notification configuration.

References

Top comments (0)