3 ms·
With Stripe, the process is: 1) Receive a webhook and record the ID in your database. If it's a duplicate, stop. 2) Ask Stripe for the event matching the ID t
by zrail 13y ago
With Stripe, the process is:
1) Receive a webhook and record the ID in your database. If it's a duplicate, stop.
2) Ask Stripe for the event matching the ID they gave you. If they reject it, stop.
3) Process the event.
It requires a roundtrip, but it's the only sane way to validate that the event you got is real and that you haven't seen it before without trying to validate a signature (lots of other APIs make you do that, though)
- rryan 13y agoYes! This is the only part of Stripe's API that I raised an eyebrow at. I think it's a little irresponsible to send all the data via web-hook without providing a way to verify it came from Stripe. At the very least they should only provide the event ID over webhook otherwise people will take the lazy route and trust trivially forgeable messages.
- pc 13y ago> I think it's a little irresponsible to send all the data via web-hook without providing a way to verify it came from Stripe. Well, as zrail said, you can trivially verify it by fetching the associated event from Stripe and ignoring the webhook body. We've debated this ourselves, though. While you can theoretically get good security with a combination of SSL and a shared secret in the URL, it's a bit ungainly, and we should perhaps encourage the right thing more straightforwardly by dropping the body from the POST.
- rryan 13y agoYou can trivially verify it by doing more work (a web request to Stripe) or you could just take the lazy route and trust the data that came with the callback. I did it the way zrail suggested but laziness typically wins especially if you aren't even aware of the reasons you might want to do it the way zrail suggested. I'm for making the right way the only way (or at least the default way).