starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Different URL for api push #2756

New issue

Closed

opened 2026-02-28 03:06:01 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-28 03:06:01 -05:00

Owner

Originally created by @notscottsmith on GitHub (Nov 7, 2023).

⚠️ Please verify that this bug has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

📝 Describe your problem

Hi,

As part of how we do security at my workplace, we use differing URLs to obfuscate services which need access without any kind of authentication in front of it (e.g. Cloudflare). Is there a way to configure Kuma to recognise a different URL for API calls being done as part of a push test for a monitor?

e.g. kuma.company.com for the status page but api.company.com/api for the API calls?

📝 Error Message(s) or Log

No response

🐻 Uptime-Kuma Version

1.23.3

💻 Operating System and Arch

Kubernetes

🌐 Browser

Firefox

🐋 Docker Version

No response

🟩 NodeJS Version

16.20.2

Originally created by @notscottsmith on GitHub (Nov 7, 2023). ### ⚠️ Please verify that this bug has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### 📝 Describe your problem Hi, As part of how we do security at my workplace, we use differing URLs to obfuscate services which need access without any kind of authentication in front of it (e.g. Cloudflare). Is there a way to configure Kuma to recognise a different URL for API calls being done as part of a push test for a monitor? e.g. kuma.company.com for the status page but api.company.com/api for the API calls? ### 📝 Error Message(s) or Log _No response_ ### 🐻 Uptime-Kuma Version 1.23.3 ### 💻 Operating System and Arch Kubernetes ### 🌐 Browser Firefox ### 🐋 Docker Version _No response_ ### 🟩 NodeJS Version 16.20.2

deekerman

2026-02-28 03:06:01 -05:00

closed this issue
added the
Stale

question

A:monitor

help
labels

deekerman commented

2026-02-28 03:06:07 -05:00

Author

Owner

@chakflying commented on GitHub (Nov 7, 2023):

The Status Pages do not need the websocket or the API to function. Have you tried setting a custom domain for your status page?

@chakflying commented on GitHub (Nov 7, 2023): The Status Pages do not need the websocket or the API to function. Have you tried setting a custom domain for your status page?

deekerman commented

2026-02-28 03:06:07 -05:00

Author

Owner

@sevmonster commented on GitHub (Dec 16, 2023):

I think what @notscottsmith is talking about is similar to what I talked about here. For example, I use a special, internal-only URL for some of my HTTP monitors that only Uptime Kuma can access, that bypasses proxy authentication and sends directly to the underlying webapp. These endpoints may also potentially shim the proxy request headers so that the application returns correct data. It would be a major security threat should a URL like this be made public, if proper mitigations are not in place/not working to make sure that external/unauthed users cannot access the service via that URL. And currently, Uptime Kuma always shows the URL for HTTPS monitors with no option to disable it.

If I'm wrong and not understanding the OP, I can open a new issue.

@sevmonster commented on GitHub (Dec 16, 2023): I think what @notscottsmith is talking about is similar to what I talked about [here](https://github.com/louislam/uptime-kuma/issues/4179#issuecomment-1843825134). For example, I use a special, internal-only URL for some of my HTTP monitors that only Uptime Kuma can access, that bypasses proxy authentication and sends directly to the underlying webapp. These endpoints may also potentially shim the proxy request headers so that the application returns correct data. It would be a major security threat should a URL like this be made public, if proper mitigations are not in place/not working to make sure that external/unauthed users cannot access the service via that URL. And currently, Uptime Kuma always shows the URL for HTTPS monitors with no option to disable it. If I'm wrong and not understanding the OP, I can open a new issue.

deekerman commented

2026-02-28 03:06:07 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 16, 2023):

@sevmonster this issue is specific to the push monitor.

I think you have not found this button on the status page:

@CommanderStorm commented on GitHub (Dec 16, 2023): @sevmonster this issue is specific to the push monitor. I think you have not found this button on the status page: ![image](https://github.com/louislam/uptime-kuma/assets/26258709/e39a6169-95fd-48a0-beb9-08e306f2417e) ![image](https://github.com/louislam/uptime-kuma/assets/26258709/d4eaa1e0-dd09-4bec-b2f2-4064f914081f)

deekerman commented

2026-02-28 03:06:07 -05:00

Author

Owner

@sevmonster commented on GitHub (Dec 16, 2023):

Thanks for reminding me about that, I forgot it existed since I never use it because of the reasons I specified. But it affects HTTP monitors too, not just push. Or really anything with a URL set in the database, as seen in #4019.

As far as I can tell the general issue is that the monitor URL (which may be internal) is used in a number of places, including status pages, Discord alerts, and as the action for Ntfy notifications. Maybe more. This can expose an internal-only URL to external users.

#1793 is also relevant.

@sevmonster commented on GitHub (Dec 16, 2023): Thanks for reminding me about that, I forgot it existed since I never use it because of the reasons I specified. But it affects HTTP monitors too, not just push. Or really anything with a URL set in the database, as seen in #4019. As far as I can tell the general issue is that the monitor URL (which may be internal) is used in a number of places, including status pages, Discord alerts, and as the `action` for Ntfy notifications. Maybe more. This can expose an internal-only URL to external users. #1793 is also relevant.

deekerman commented

2026-02-28 03:06:07 -05:00

Author

Owner

@github-actions[bot] commented on GitHub (Mar 18, 2024):

We are clearing up our old help-issues and your issue has been open for 60 days with no activity.
If no comment is made and the stale label is not removed, this issue will be closed in 7 days.

@github-actions[bot] commented on GitHub (Mar 18, 2024): We are clearing up our old `help`-issues and your issue has been open for 60 days with no activity. If no comment is made and the stale label is not removed, this issue will be closed in 7 days.