[Perseids]

Thanks for your remarks and corrections.

While what you say is correct, it doesn't apply to the problem Troy Hunt faced. What he needs is DDOS protection on his API. The request authentication Stripe provides is too complicated to be checked by the web application firewall.

The (edit:) pragmatic approach is to

a) not use webhooks or

b) let Stripe connect to you via HTTPS (to prevent replay attacks and leakage of the secret URI), give Stripe a secret URI, whitelist the secret URI in the WAF and verify the payload MAC via the official SDK.

> in order to give feedback to the user fast about the status of his payment (and not wait the next long polling iteration)

Nitpick: The long poll / Server Sent Event should respond immediately once there is new data available, so it should not be slower than the webhook.

[PeterisP]

> b) let Stripe connect to you via HTTPS (to prevent replay attacks and leakage of the secret URI), give Stripe a secret URI, whitelist the secret URI in the WAF and verify the payload MAC via the official SDK.

IMHO the long term best architecture would be HTTPS client certificates / mutual TLS auth- you would just whitelist that only clients signed/approved by Stripe can connect to that Stripe-callback endpoint.

[masklinn]

Maybe but the feasibility takes a huge dive, because you now need the application to terminate tls (or additional configuration for the route wherever TLS is terminated), plus a flow to rotate certificate.

[robertlagrant]

From memory, I think that's how Twilio callbacks work.