An e-commerce site should reserve products for a user while they're going through the payment process (more info). This creates a potential denial-of-service risk where an attacker could reserve many products and never complete payment - reserving all the stock and preventing legitimate sales.

How can this be defended against?

One option I considered is doing as much verification as possible on the user before allowing reservations. But there's not much verification you can do - the whole idea is that anyone can buy from your store. You could potentially require a verified email, but that's inconvenient for users, and it's still quite easy for an attacker to verify a large batch of emails.

  • 2
    I think it's more of a business logistics issue. You have an expected rate of abandoned carts, and you have an ability for JIT manufacturing. You don't typically warehouse everything; you have an optimisation curve. – schroeder Jul 9 '20 at 12:48
  • @schroeder - Sure, if you can JIT, this isn't an issue. Question was more around products you can't JIT, e.g. things manufactured offshore in batches. In the latter case, the business decision is clear: don't let people DoS. My question is how can IT implement this? – paj28 Jul 9 '20 at 12:57
  • 1
    Fair enough. Actually, I know someone who launched a tech start-up just for this ... Let me get her attention on your question. – schroeder Jul 9 '20 at 13:02
  • Right. It falls into the "wicked problem" domain. Abandoned cart management processes are the key to try to verify legitimate orders. – schroeder Jul 9 '20 at 13:30
  • 2
    @reed Amazon will notify the user even as late as the payment screen if something in their cart goes out of stock. But once you get to the payment screen and START a payment, then the products are "reserved" for ~2 hours or so even if the payment fails. The keyword being start here, since valid payments methods are harder to forge in bulk than user accounts or phone numbers. – Kartik Soneji Jul 10 '20 at 0:49

I've seen 2 main solutions:

Your products are being reserved for X minutes

I've seen notices like this occasionally, but only on places where inventory really matters (usually ticketing sites).

I've also built a number of eCommerce sites for small businesses, and their preferred solution is always the same:

Just ignore it

It's often just not a critical factor, even if you don't have JIT manufacturing capabilities. Sometimes you can just have it drop shipped from the manufacturer. Most of the time the turn over on your inventory is low enough that it just doesn't matter. Sometimes you have to reach out to the customer after they place the order and let them know about the delay.

In short, this is more of a business problem, and not all businesses care.

  • Thank for the pragmatic response. Other answers claimed this was essential, but I figured it's rare in practice because it's difficult to implement well. – paj28 Jul 9 '20 at 15:17
  • @paj28 I also worked primarily with smaller businesses, most of which didn't have the technical capabilities (in terms of live-and-accurate inventory tracking) to implement this. Although to be fair it's not just small businesses that have this issue. I've often called larger retail establishments (think Lowes, Home Depot, Best Buy) because I want to check availability of the item and have been told, "The system says we have a couple in stock but sometimes that means we're out, so let me check". You can't tightly control ordering if you don't know how much you have in stock. – Conor Mancone Jul 9 '20 at 17:39
  • @ConorMancone Amazon does this by default. If your payment fails or is interrupted midway, then you can retry the payment and the products are still "reserved" for you. I think the important bit is having a valid payment method before reserving, since they are harder to forge in bulk then user accounts or phone numbers. Then you can easily implement rate-limiting by checking how many products are reserved by each payment method instead of per user account. – Kartik Soneji Jul 10 '20 at 0:53
  • 1
    "Essential" is a strong word, but it really depends on the business. For in-demand ticketing sites with reserved seats, I'd say it's essential because it would be really hard to complete transactions without some kind of reservation (click seat A105, enter payment details, oops—A105 is now sold out, back up, click seat G102, enter payment details, oops—G102 is now sold out, and so on). For normal consumer goods with steady demand patterns, dealing with it may just not be a business priority. – Zach Lipton Jul 10 '20 at 2:59

Abandoned cart management processes are the key to try to verify legitimate orders. Use your expected order patterns even in periods of order spikes. Get engagement from users by nagging them about their abandoned cart. If they don't engage with the email or log back in, even after enticement, you can write-off the order.

Not exactly a security-based solution, but it's what's done in practice.

  • Did you have any particular abandoned cart processes in mind? Sure, we can nag the user and release the reservation after a timeout, or failure to engage. But that doesn't fully prevent the DoS risk. I have a feeling most sites do little about this in practice. – paj28 Jul 9 '20 at 13:37
  • Your feeling is correct, and that's why my friend started her company. It still didn't do very well because most vendors don't have a need for this level of optimisation. They are either handling it using logistics or delays. It's also not a huge problem. If you are ordering in batches, then you factor that into your schedule. And you tend not to reserve orders until verified payment. If you want fast turnaround times in manufacturing, then you're in JIT territory. – schroeder Jul 9 '20 at 13:55
  • Abandoned cart: nag within 12 hours, offer small discount, highlight oft-also-ordered products, mention the time sensitivity of ordering else experiencing a fulfilment delay. If email is unopened within 12 hours: dump the reservation. If email is opened; start a sales funnel process, but dump after 48 hours regardless. – schroeder Jul 9 '20 at 13:58
  • There's a reason why Amazon has an "order now to get with X days" on the sales page, but not the cart. If you come back to your cart after their timeout, yo'll get it when you get it :) – schroeder Jul 9 '20 at 14:01
  • Reserving after payment introduces a small risk of a negative user experience (explained here) I'd be really interested to see a link to your friend's company. – paj28 Jul 9 '20 at 14:12

Reservation is a privilege

If we can, we reserve products during checkout:

  • Returning users - who have previously made and paid for an order. Their account is more trusted and can reserve products any time.

  • New users:

    • At normal times, they can reserve products during checkout.
    • If the there's ongoing DoS attempts, new users are not allowed to reserve products. A warning could be included on the order page, but I'm not going to as it will probably just cause confusion.

To implement this, there needs to be a "defcon" level, presumably based on things like number of abandoned checkouts in the past hour.

Schroeder suggested behavioural analysis could be used to determine if the user is human. This would be pretty neat, but I'm not going to code behavioural analysis myself. If there's an open-source solution maybe I'd use that.

Edit - Square's API helps

I've realised that Square's API helps a lot with this. With their API, client-side code generates a single-use payment token. This is submitted, then server-side code charges the token.

When the token is submitted, the app can check stock levels. It's not too bad an experience for the user if they enter their details, but the order fails before the card is charged. The app doesn't need to reserve stock while the user enters card details. And I expect a DoS is less likely as you can't easily obtain Square tokens in bulk (although I haven't tested that!)

This arrangement is somewhat like two-phase commit.

  • 1
    If this is about things like quickly sold-out concert tickets, it may be the case that new customers never make it to a successful order because they didn't manage to do so last time ... – Hagen von Eitzen Jul 10 '20 at 6:08
  • @HagenvonEitzen - Yep, that's definitely a problem. There's a number of tradeoffs to be made here and I'd say this arrangement is the least bad overall. But if you can suggest a way to avoid the new customer problem without re-introducing one of the other problems, I'd love to hear it! – paj28 Jul 10 '20 at 13:29

I understand that the "I am not a robot" tick box, is running analysis on mouse movement. And in fact the technology underneath doesn't require you to actually tick a box; it's just looking for some mouse mouse movement data to input into a machine learning algorithm. The algorithm then decides if you're human or not.

Perhaps this process could be applied to the "Add to Cart" button, (instead of a "I'm not a Robot" checkbox).

Establishing that a user is a real user before reserving stock, would make your DoS attack much more difficult (perhaps prohibitively difficult).

This is the process used by Google's reCapture 3, so it should be very easy to implement. (thanks to @paj28 in the comments)

  • It's called a CAPTCHA. You're suggesting to add Google's reCAPTCHA code to the order page. – schroeder Jul 10 '20 at 7:43
  • @schroeder, I read this as suggesting to run mouse movement analysis on the order page to tell real customers from robots. Less visible to the user, more complicated for the programmer. – o.m. Jul 10 '20 at 11:47
  • @o.m. - That's essentially what reCAPTCHA 3 does – paj28 Jul 10 '20 at 13:28
  • @paj28, ah, I was thinking of reCAPTCHA 2. – o.m. Jul 10 '20 at 13:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.