This chapter tells a real-world story of a subtle but costly security flaw in an online store: accepting negative quantities for items, the “anti-Hamlet.” Rather than a broken firewall or web server, the problem stemmed from a breach of business integrity—logic that allowed nonsensical operations to pass as valid. The narrative shows how shallow, ad hoc modeling choices (like treating quantity as an unrestricted integer) can let defects hide in plain sight, and it contrasts this with the mindset and practices of deep modeling as a way to prevent such losses.
When a tester entered a quantity of -1 for a $39 book, the order was processed end-to-end without errors. The billing system ignored the negative amount, the accounts receivable ledger interpreted it as money owed to the customer and created a credit invoice, the inventory increased stock as if a book had been returned, and the shipping system silently discarded the negative line after logging an exception no one read. Because inventory and accounting “lived the same lie,” nightly and quarterly reports showed no mismatch, and the issue surfaced only through a suspicious accounting address and later through warehouse count discrepancies. Customers had already discovered the loophole and used negative items as do-it-yourself discounts; leadership chose not to pursue repayment, closed the hole, and moved on.
The root cause was shallow modeling: representing important business concepts with permissive primitives (ints, strings, floats) without capturing constraints or meaning. The remedy is deep modeling: collaborate with domain experts to define explicit domain concepts (for example, a Quantity that must be positive and within operational limits, and a Money type), encode rules where the concepts live, and make implicit assumptions explicit. This approach, inspired by domain-driven design, yields clearer code, enforces business integrity at the model boundary, reduces security risk, and prevents entire systems from consistently reinforcing the same faulty assumptions.
Figure 2.1. The normal flow when Joe buys two copies of Hamlet at $39 each
Figure 2.2. The "to pay" value of a negative book in a shopping cart
Figure 2.3. Online store sending -$39 to billing and to the accounts receivable ledger.
Figure 2.4. Accounts receivable ledger sending a credit invoice and clearing the ledger.
Figure 2.5. Joe Tester orders -1 Hamlet.
Figure 2.6. Do-it-yourself discounting—add an anti-Hamlet
Figure 2.7. The how-can-I-code-this mindset at work
Summary
Incomplete, missing, or shallow modeling leads to a design with security flaws.
A security flaw in the form of broken business integrity can live in production for a long time, bleeding money from your enterprise.
Conscious, explicit design results in a much more robust solution.
FAQ
What is the “anti-Hamlet” bug in this chapter?The online store accepted a negative quantity (e.g., -1 of Hamlet). This made the order total negative, effectively paying customers or discounting their carts, while also increasing inventory counts instead of decreasing them.Why didn’t standard security testing (infrastructure, XSS, SQLi) catch this?Because nothing was technically “broken.” Firewalls, sessions, and inputs were hardened. The flaw was a business integrity issue caused by incorrect domain modeling, not an infrastructure or typical web exploit.How did the different backend systems react to a negative quantity?- Billing: Treated a negative amount as “nothing to collect,” so it did nothing. - Accounts receivable: Created a credit invoice, attempting to pay the customer. - Inventory: Increased stock (subtracting -1). - Shipping: Threw an exception and silently dropped the line.Why didn’t nightly or quarterly reports reveal the problem?The systems were consistently wrong. Inventory and accounting “agreed” on the same false state, so cross-system checks passed. The mismatch with physical stock surfaced only at year-end manual inventory.How did customers exploit the flaw in practice?They added negative items to their carts to reduce the total payable—turning the bug into a do-it-yourself discount voucher. Some also received credit invoices.What does the book mean by a breach of “business integrity”?Data violated business rules while remaining technically valid. Paying out money for anti-books or increasing stock when something is “sold” breaks the intended business invariants, constituting a security failure of integrity.How did shallow modeling cause this?Quantity was modeled as an unrestricted integer. Without domain rules (no negatives, meaningful upper bounds, zero handling), the system allowed values that broke business invariants.What would deep modeling do differently?Make implicit concepts explicit. For example, create a Quantity type that enforces positivity (and sensible upper limits), use a Money type (not float/double), and introduce domain types like ISBN and BookTitle with their own constraints.Why is representing money as float/double a bad idea?Floating-point rounding errors can corrupt financial calculations. Use a precise money representation (e.g., decimal with currency or a dedicated Money type) to preserve integrity and avoid subtle bugs.How can teams prevent similar issues?- Validate domain invariants at boundaries and in core models (e.g., positive quantities). - Use explicit domain types rather than primitives. - Discuss and encode limits (upper/lower bounds). - Add cross-system checks tied to real-world state (e.g., periodic physical-to-system reconciliation). - Monitor and alert on anomalous values (negative totals, zero-quantity lines). - Include business-rule tests and property-based testing for edge cases.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
Secure by Design ebook for free
