starred/healthchecks

Fork 0

mirror of https://github.com/healthchecks/healthchecks.git synced 2026-04-25 23:15:49 +03:00

[GH-ISSUE #1148] Use human-readable API key prefixes to distinguish read-only and read-write API keys #793

New issue

Closed

opened 2026-02-25 23:43:36 +03:00 by kerem · 5 comments

kerem commented

2026-02-25 23:43:36 +03:00

Owner

Originally created by @hartwork on GitHub (Apr 19, 2025).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1148

Hi!

It has come to my attention that there is a (good) warning "Be sure to use the read-only API keys!" in the readme of https://github.com/healthchecks/dashboard and that made me remember that the problem could be prevented by design and altogether by using slightly different syntax for these two kinds, e.g. the read-only ones always starting with R and the writable ones starting with W. That would allow the backend to detect and reject token mix-up safely and easily.

The idea is from article https://blog.hboeck.de/archives/909-Mixing-up-Public-and-Private-Keys-in-OpenID-Connect-deployments.html where the consequences of mix-up were even more severe.

Thanks for your consideration!

CC @hannob

Originally created by @hartwork on GitHub (Apr 19, 2025). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1148 Hi! It has come to my attention that there is a (good) warning "Be sure to use the read-only API keys!" in the readme of https://github.com/healthchecks/dashboard and that made me remember that the problem could be prevented by design and altogether by using slightly different syntax for these two kinds, e.g. the read-only ones always starting with `R` and the writable ones starting with `W`. That would allow the backend to detect and reject token mix-up safely and easily. The idea is from article https://blog.hboeck.de/archives/909-Mixing-up-Public-and-Private-Keys-in-OpenID-Connect-deployments.html where the consequences of mix-up were even more severe. Thanks for your consideration! CC @hannob

kerem

2026-02-25 23:43:36 +03:00

closed this issue
added the
feature
label

kerem commented

2026-02-25 23:43:37 +03:00

Author

Owner

@cuu508 commented on GitHub (Apr 22, 2025):

Adding prefixes to distinguish read-only and read-write keys is a good idea. We could do that for new keys going forward. The prefixes would make it easier for humans to spot mistakes.

I don't see how prefixes would help backend reject "wrong" keys. The read-write keys allow read operations, they are not write-only keys. When the backend receives a read operation but with a read-write key, how would it decide whether to reject it?

@cuu508 commented on GitHub (Apr 22, 2025): Adding prefixes to distinguish read-only and read-write keys is a good idea. We could do that for new keys going forward. The prefixes would make it easier for humans to spot mistakes. I don't see how prefixes would help backend reject "wrong" keys. The read-write keys allow read operations, they are not write-only keys. When the backend receives a read operation but with a read-write key, how would it decide whether to reject it?

kerem commented

2026-02-25 23:43:37 +03:00

Author

Owner

@hartwork commented on GitHub (Apr 22, 2025):

Adding prefixes to distinguish read-only and read-write keys is a good idea. We could do that for new keys going forward. The prefixes would make it easier for humans to spot mistakes.

@cuu508 cool!

I don't see how prefixes would help backend reject "wrong" keys. The read-write keys allow read operations, they are not write-only keys. When the backend receives a read operation but with a read-write key, how would it decide whether to reject it?

It may need an API endpoint (or mode) dedicated to read-only access and read-only keys that would reject read-write keys.

@hartwork commented on GitHub (Apr 22, 2025): > Adding prefixes to distinguish read-only and read-write keys is a good idea. We could do that for new keys going forward. The prefixes would make it easier for humans to spot mistakes. @cuu508 cool! > I don't see how prefixes would help backend reject "wrong" keys. The read-write keys allow read operations, they are not write-only keys. When the backend receives a read operation but with a read-write key, how would it decide whether to reject it? It may need an API endpoint (or mode) dedicated to read-only access and read-only keys that would reject read-write keys.

kerem commented

2026-02-25 23:43:37 +03:00

Author

Owner

@cuu508 commented on GitHub (Jun 2, 2025):

Implemented in #1167

@cuu508 commented on GitHub (Jun 2, 2025): Implemented in #1167

kerem commented

2026-02-25 23:43:37 +03:00

Author

Owner

@hartwork commented on GitHub (Jun 2, 2025):

Implemented in #1167

@cuu508 thank you! To be sure I understood the changes right: endpoint GET /api/v3/checks/ would not reject accidental use of read-write API keys or at least not yet, correct?

@hartwork commented on GitHub (Jun 2, 2025): > Implemented in [#1167](https://github.com/healthchecks/healthchecks/pull/1167) @cuu508 thank you! To be sure I understood the changes right: endpoint `GET /api/v3/checks/` would not reject accidental use of read-write API keys or at least not yet, correct?

kerem commented

2026-02-25 23:43:37 +03:00

Author

Owner

@cuu508 commented on GitHub (Jun 2, 2025):

Correct, GET /api/v3/checks/ accepts both read-write and read-only keys.

@cuu508 commented on GitHub (Jun 2, 2025): Correct, `GET /api/v3/checks/` accepts both read-write and read-only keys.