Home / Knowledge hub / Negative quantity
Knowledge hub
Negative quantity
A numeric field accepting values below zero so balances move the wrong way.
What it means
A negative quantity flaw is a business-logic bug where a field that should hold a positive number accepts zero or a negative one, and the maths still runs. Buying minus two items produces a refund, a transfer of minus ten moves money the other way.
The code usually does exactly what it was written to do. It adds a quantity times a price to a total. Nobody thought about a quantity below zero, so the same sum quietly pays the buyer instead of charging them.
Why it matters
The result can be money paid out for nothing: credit added to an account, a total that falls below what was owed, or stock that rises. When it affects balances, points or inventory, it can be repeated until someone notices.
It is cheap to fix and costly to miss. The weakness belongs to the group of numeric range errors that MITRE tracks, and it often sits beside price manipulation. Finance teams find it later as a figure that does not reconcile.
How it shows up
Look at any field that carries a count or amount: cart quantity, transfer amount, seat count, loyalty points, refund value. Also check values near the limits: zero, very large numbers that overflow, decimals where only whole numbers make sense, and numbers sent as text.
Validate on the server, with a minimum and a maximum for each field, and the correct type. Reject anything outside it rather than correcting it silently. Repeat the checks at the point the balance changes. Test by sending negative, zero and huge values on every numeric field. See input validation.
Questions people ask
Negative quantity, answered
Why would software accept a negative number?
Because the field's type allows it. A signed integer holds negatives, and the code never checked for them. The calculation then works with the number as given.
The mistake is to assume the front end limits the value.
Is this the same as an integer overflow?
No, though they are close relatives. Negative values are a logic problem: the number is legal but unwelcome. Overflow happens when a number is too large for the space reserved for it.
Test for both on numeric fields.
Does a front-end minimum protect us?
No. Browser limits only affect people using the interface. A request sent directly can contain any value.
Enforce the range on the server, and reject anything outside it. Do the same check again where the balance actually changes.
Where are negative values most dangerous?
Anywhere a balance, stock level, loyalty score or refund is changed by a user-supplied amount: wallets, transfers, refunds and cart quantities.
Check also the opposite direction, such as a withdrawal of a negative amount.
How do we test for it?
Send minus one, zero, a very large number and a fraction in each numeric field, then compare the resulting balances, totals and stock with what you expect.
Try the same on every API endpoint that accepts numbers, not only the web forms.
Sources
Where this comes from
Related
Terms that sit next to this one
Price manipulation
Changing a price, quantity or discount in a request so you pay less than you should.
Input validation
Checking that what arrives is the shape and range you expected.
Parameter tampering
Changing values in a request, such as a price or an id, to alter what happens.
Rounding abuse
Exploiting how amounts are rounded to gain tiny sums repeated many times.
Business logic flaw
Nothing is technically broken, but your own rules turn against you.
What if the number is below zero?
We check numeric fields in your flows for values the business never expected and show the balance or total that moved. Business-logic flaws like this are in scope, with the request and response as proof. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.