Skip to main content

According to the current Webhooks Events API documentation, only the client authenticates to Strava upon subscription registration/check, with the API client_id and client_secret.

This is great but IMO insufficent, as both parties should somehow be authenticated. In other words, Strava should authenticate with the Webhook suscriptor. The way is done at the moment, an attacker could impersonate Strava's API sending fake event data to the client's endpoint. The only way the client could defend from this would be checking whether if the subscription ID matches or not. But this is neither proposed as a security measure in the documentation site, or implicit within the process (it's something that the clients would need to implement ad-hoc). Moreover, since the subscription_id field is integer, it could be pretty easy for an attacker to guess the right value.

Is there any other way of dealing with this that you could suggest?

Thanks in advance.

Hello everyone.

I have the same security problem regarding the Strava webhook, I consider the "subscription Id" check insufficient.

Only include the hub.verify_token in the GET method (when it would also be necessary in the POST method).

I would need an answer please to know if there is another way to secure (because there is nothing like that in the official documents) the webhook.

Regards.


It is only you and Strava that can (should) know the subscription_id. You could do an additional check to verify that the request origin is coming from Strava. Otherwise, you can valid the individual events, and add rate limiting to mitigate ddos attempts.


It's funny that we have to use the complicated oauth workflow for authentification and authorization but Strava wants to access our systems without any standardized authentication. That prevents me from using webhooks at all.


Reply