#noahlt-detach-payment
paper nexus
What call are you making that is asking for a Customer ID?
Oh, you said why doesn't it
Because only one Payment Method ID is assigned per Customer, so providing the Customer ID would be redundant
loud fractal
wait, but you can attach multiple PaymentMethods to a single Customer
eg, you can list PaymentMethods of a Customer: https://stripe.com/docs/api/payment_methods/customer_list?lang=go
paper nexus
Right, but when you detach a Payment Method, it only pulls it from the one Customer it's attached to. What specific scenario are you trying to mitigate?
loud fractal
specifically, a user Mal somehow gets ahold of another user Alice's PaymentMethod ID, then spoofs a request to my server with Alice's PaymentMethod ID, which in turn makes a request to /v1/payment_methods/:id/detach (again, with Alice's PaymentMethodID).
Result: Mal has detached Alice's PaymentMethod from her Customer, and next time we try to charge Alice, it will fail due to having no PaymentMethods.
does that… make sense? am I missing something that makes this attack impossible?
paper nexus
I think we only thought of that in terms of a bad actor trying to reuse the Payment Method, so we disallowed re-use of Payment Methods (e.g. once you attach a Payment Method, it cannot be used again on another customer, even if it it detached).
As for the use-case you mentioned: Mal would have to have your API key in order to list the Payment Methods for Alice and (if Mal did) then detaching Customer Payment Methods would be the least of your worries as far as I can tell
loud fractal
uhhh okay I have a follow-up question: should I not be sending PaymentMethod IDs to my client? 😅
I have one endpoint that lists PaymentMethods and sends them to my client, and another endpoint that accepts a PaymentMethodID and basically forwards that request to the Stripe Detach Payment Method endpoint. (Maybe this is the wrong way to allow users to delete PaymentMethods?)
(thank you so much, btw)
paper nexus
You can definitely send those to your client, but if you're sending them to your client, then you should be putting that functionality behind a secure login portal/dashboard where bad actors can't get to it.
loud fractal
ah okay, so the Stripe-recommended threat model is "once a paying customer is securely authenticated, assume they are not a bad actor"?
paper nexus
No, definitely not. From a security standpoint I think it would be fair to operate as though any user could be a bad actor in disguise. Mostly the point I'm making is that Stripe can only control so much of the any given integration's security, so there are auth measures in place for highly sensitive things (e.g. creating payments, reusing Payment Methods, copying/accessing Customer data, etc.), but some actions (e.g. detaching a payment method) rely on you to protect your API key and restrict access to functionality that uses it.
So, if you're worried about people detaching the Payment Method, then add additional security measures to ensure that the right person is accessing it. Specifically for handling client-side security, we link out to the OWASP guide here: https://stripe.com/docs/security/guide#additional-security-considerations
loud fractal
Got it, ok. So I do, in fact, need to verify that the provided PaymentMethodID actually does belong to the Customer making the request before I detach the PaymentMethod.
Ultimately I think I was just confused because I have trouble imagining a use case where this verification would not be necessary, but, I'm sure there is one
paper nexus
That's fair, and it might be that it's a better idea to do that, but also I'm not sure in what case a bad actor would end up with the Payment Method ID and not the Customer ID
loud fractal
Ah, yeah that makes sense. Hey, thanks for patiently answering my questions while I badgered you about this API!