Defending against DoS via product reservation
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.
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.
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.