3 ms·
Be careful, you might be charged for Radar processing and that can easily add up to thousands in fees when card testers target your site. You should really be i
by fastest963 4y ago
Be careful, you might be charged for Radar processing and that can easily add up to thousands in fees when card testers target your site. You should really be implementing rate limiting and CAPTCHAs to prevent any issues.
- sgc 4y agoHow do you use captchas when the requests are not even coming from your site as the article indicated? It seems odd this is even possible, does stripe not allow you to register an ip whitelist for token generation etc so that at least part of the payment process must go through your site? It seems like stripe rate limiting is just on the api level, so you would need to implement your own ip based rate limiter on you site, if you could force part of the process to go through it.
- nightpool 4y agoWell, obviously all bets are off when an attacker compromises your Stripe private key. I think that's a bit of an exceptional case, it's kind of silly to blame Stripe for it when such an devastating vulnerability existed in the site.
- sgc 4y agoI agree, and think the article writer agrees, it was mainly their fault (after the actual fraudster of course). I still genuinely don't understand why such a basic thing as ip restriction is not part of the security settings in stripe. I keep looking for it thinking I must be missing it. On the user's site, it could be as simple as a fail2ban rule to deal with most of this. And no doubt he is not the only one to have done such a thing, given the number of libraries and frameworks people throw on their sites, all with their own layers of configuration.