You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
Description
TruffleHog incorrectly alerts on PostHog's public client-side API keys and does not test their server-side private API keys.
From Posthog's Documentation:
One API is used for pushing data into PostHog. This uses the 'Team API Key' that is included in the frontend snippet. This API Key is public, and is what we use in our frontend integration to push events into PostHog, as well as to check for feature flags, for instance....The other API is more powerful and allows you to perform any action as if you were an authenticated user utilizing the PostHog UI. This uses a 'Personal API Key' which you need to create manually. This API Key is private...
At the moment, TruffleHog tests PostHog's 'Team API Key', but not 'Personal API Key'.
Problem to be Addressed
The current PostHog detector verifies whether a PostHog API key can reach the https://app.posthog.com/decide/ endpoint, which is used by their client-side JS snippet to track user behavior. This API key and endpoint are designed to be public. In contrast, an endpoint like https://app.posthog.com/api/event/?personal_api_key={key} uses the 'Personal API Key', which is designed to be private.
Sending the public API key to a private endpoint returns a 401 and this response:
{"type":"authentication_error","code":"authentication_failed","detail":"Personal API key found in request query string is invalid.","attr":null}
Sending a private API key to the private endpoint returns a 200 and this response (for an empty account):
{"next":null,"results":[]}
Description of the Preferred Solution
Change the PostHog detector in a few places:
The API Key regex needs to change from (phc_[a-zA-Z0-9_]{43}) to (phx_[a-zA-Z0-9_]{43}). Note the difference is the phx prefix.
It needs to attempt up to 2 GET requests. The reason for 2 attempts is PostHog uses two different domains for their clients based on geography - one for US customers app.posthog.com and one for EU customers eu.posthog.com. If one returns 200, then the other GET request can be avoided. If the first returns 401, then the second geography endpoint should be tested.
Community Note
Description
TruffleHog incorrectly alerts on PostHog's public client-side API keys and does not test their server-side private API keys.
From Posthog's Documentation:
At the moment, TruffleHog tests PostHog's 'Team API Key', but not 'Personal API Key'.
Problem to be Addressed
The current PostHog detector verifies whether a PostHog API key can reach the
https://app.posthog.com/decide/
endpoint, which is used by their client-side JS snippet to track user behavior. This API key and endpoint are designed to be public. In contrast, an endpoint likehttps://app.posthog.com/api/event/?personal_api_key={key}
uses the 'Personal API Key', which is designed to be private.Sending the public API key to a private endpoint returns a
401
and this response:Sending a private API key to the private endpoint returns a
200
and this response (for an empty account):Description of the Preferred Solution
Change the PostHog detector in a few places:
(phc_[a-zA-Z0-9_]{43})
to(phx_[a-zA-Z0-9_]{43})
. Note the difference is thephx
prefix.It needs to attempt up to 2 GET requests. The reason for 2 attempts is PostHog uses two different domains for their clients based on geography - one for US customers
app.posthog.com
and one for EU customerseu.posthog.com
. If one returns200
, then the other GET request can be avoided. If the first returns401
, then the second geography endpoint should be tested.Additional Context
References
The text was updated successfully, but these errors were encountered: