[GH-ISSUE #877] Redact Ping URL for read-only users #618

Closed
opened 2026-02-25 23:43:04 +03:00 by kerem · 1 comment
Owner

Originally created by @anymuster2 on GitHub (Aug 10, 2023).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/877

Hi,

Currently there exists a 'read-only' user role - implying the user can access but not modify the page, but the ping URLs are exposed to the user. This creates the scenario where a user could configure a cron job to trigger a ping URL, resulting in falsified data. I also assume but have not checked that the read-only APIs are similar (e.g., they also expose the ping URL).

Take the following scenario: A service with a healthcheck relies on transport infrastructure, the user is not responsible for the service but is responsible for any outages caused by transport infrastructure - the user should not have knowledge of the URL, but needs to know if the relevant service is offline.

I'd propose that exposure of token URLs is configurable to be redacted either based on user role, flag on the invite, or environment var. In some comparable scenarios (API token generation) on unrelated services, the secret is exposed to the creator only once - e.g., the UI will never reflect the secret again.

Originally created by @anymuster2 on GitHub (Aug 10, 2023). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/877 Hi, Currently there exists a 'read-only' user role - implying the user can access but not modify the page, but the ping URLs are exposed to the user. This creates the scenario where a user could configure a cron job to trigger a ping URL, resulting in falsified data. I also assume but have not checked that the read-only APIs are similar (e.g., they also expose the ping URL). Take the following scenario: A service with a healthcheck relies on transport infrastructure, the user is not responsible for the service but is responsible for any outages caused by transport infrastructure - the user should not have knowledge of the URL, but needs to know if the relevant service is offline. I'd propose that exposure of token URLs is configurable to be redacted either based on user role, flag on the invite, or environment var. In some comparable scenarios (API token generation) on unrelated services, the secret is exposed to the creator only once - e.g., the UI will never reflect the secret again.
kerem closed this issue 2026-02-25 23:43:04 +03:00
Author
Owner

@cuu508 commented on GitHub (Aug 10, 2023):

I also assume but have not checked that the read-only APIs are similar (e.g., they also expose the ping URL).

The API calls do not expose ping URL when using the read-only API key. For example, see the example API responses for the "List Existing Checks" API call: https://healthchecks.io/docs/api/#list-checks

When using the regular API key, responses contain a ping_url field. When using the read-only key, responses instead contain a unique_key field. The unique key is derived from the check's UUID using one-way function.

You can build a public dashboard that shows check statuses but gives no access to ping URLs using the read-only API keys. Pointers:

You can also use status badges, they also do not disclose ping URLs.

<!-- gh-comment-id:1672679481 --> @cuu508 commented on GitHub (Aug 10, 2023): > I also assume but have not checked that the read-only APIs are similar (e.g., they also expose the ping URL). The API calls do not expose ping URL when using the read-only API key. For example, see the example API responses for the "List Existing Checks" API call: https://healthchecks.io/docs/api/#list-checks When using the regular API key, responses contain a `ping_url` field. When using the read-only key, responses instead contain a `unique_key` field. The unique key is derived from the check's UUID using one-way function. You can build a public dashboard that shows check statuses but gives no access to ping URLs using the read-only API keys. Pointers: * https://github.com/healthchecks/dashboard * https://github.com/nicoandrade/healthchecks-front You can also use [status badges](https://healthchecks.io/docs/badges/), they also do not disclose ping URLs.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/healthchecks#618
No description provided.