Business Logic and File Upload Testing

Why it matters

Vulnerability scanners rarely find these defects, because nothing is technically malformed: the request is valid JSON, the file is a valid upload. Only a tester who understands what the business intends can see that discount: 100 or a second confirm should have been refused. OWASP lists this class twice: Insecure Design (A06:2025) in the Top 10, and Unrestricted Access to Sensitive Business Flows (API6:2023) in the API Security Top 10, where automated abuse of a purchase, booking or sign-up flow is the stated risk.

The cost is direct money and trust: free orders, drained coupons, stock bought out by bots, and an uploaded file that executes on the server or runs script in another user's browser. For the tester, this is the part of security testing that needs the least tooling and the most thinking, and it is where functional testing skills transfer directly.

Workflow abuse: skipped steps and tampered fields

Every multi-step flow is a state machine: cart, coupon applied, awaiting payment, paid, confirmed. The browser shows the steps in order, but the server receives separate requests and must check, on every one, that the order is in the right state. Testing starts by listing the states and the requests that move between them, as in the lesson on state transition testing, then trying the moves the design does not allow: calling the confirmation request before payment, reordering steps (choosing shipping after paying), or repeating a step that should happen once.

The second group of tests changes values the server should own. Price, discount, total, currency, role and is_admin fields have no business arriving from the client; if they do, change them and see whether the server recomputes or believes them. Add the negative and extreme values you know from boundary value analysis: quantity -1 (a refund disguised as a purchase), 0, 999999, a discount of 101 percent, a price of 0.001.

• Skip: send the last step first. Expected: a 4xx error and no change of state.
• Reorder and repeat: pay twice, confirm twice, apply a coupon to an empty cart. Expected: the second call is refused or is a harmless no-op.
• Tamper: change price, total, discount or role in the request, as in the payment request below for an order of 1,899.00. Expected: 400 or 422, or the field is ignored; either way the server uses its own values and the response shows them. A 200 that charges 1.00 is the defect.
• Limits and reuse: one coupon per customer, three attempts per hour, five items per order. Expected: the server counts each use, so the limit holds across sessions, devices and page reloads, and a code meant to be used once in total also fails from a second account.

POST /orders/8841/pay HTTP/1.1
Host: shop.example
Content-Type: application/json
Cookie: session=...

{ "payment_token": "tok_test_123", "total": 1.00, "currency": "SAR" }

Try it: State Transition Generator Try it: API Request Builder

Race conditions: the same request twice at once

A race condition is a defect that appears only when two or more requests touch the same record at nearly the same time. The classic case is double spend: a wallet holds 100 SAR, two withdrawals of 100 SAR arrive together, both read the balance before either writes it, and both succeed. The same shape produces two orders from one double-click on "Place order", a single-use coupon redeemed twice, or a limit of five attempts that lets six through.

At this level the concept matters more than the tooling. The expected behaviour is that the server makes the check and the change in one indivisible (atomic) step, usually with a row lock inside a database transaction, an update that succeeds only if the balance is still enough, or a unique constraint, so that exactly one request wins. To test, submit the same request two or more times with as little delay as possible (two tabs, a script that fires in parallel, or the repeat function of an intercepting proxy) and compare the final state with what one request should produce. Idempotency keys on payment requests, which you may see as an Idempotency-Key header, are the design answer for retries and worth asking the developer about.

• Double submit: the order button pressed twice. Expected: one order, one charge, one e-mail.
• Double spend: two withdrawals or redemptions at once. Expected: exactly one succeeds and the balance never goes below zero.
• Counter limits: many parallel attempts against a limit. Expected: the limit holds exactly; the attempt after the limit is refused however the requests are timed.

Try it: Edge Case Generator

File uploads: name, type, size, content and where it lands

An upload gives the application three things that can disagree: a file name with its extension, a declared media (MIME) type in the Content-Type of the multipart part, and the bytes themselves. The client chooses the first two freely. A file called report.pdf with Content-Type application/pdf can contain an HTML page. Secure handling, as the OWASP File Upload Cheat Sheet describes it, is an allow list of extensions, a check of the actual content (its file signature, the first bytes that identify the format, and for images rewriting them), a size limit, a server-generated file name, and storage on a separate host or outside the web root (the folder the web server serves files from), where the server will not run the file as code.

The second half of the test is what happens when the file is served back. A stored HTML or SVG file opened at a URL on the application's own origin runs script with the user's session: a stored XSS delivered by upload. Safe responses send the exact Content-Type the server decided on, X-Content-Type-Options: nosniff, and Content-Disposition: attachment (the browser downloads the file instead of displaying it) for anything other than a raster image such as PNG or JPEG whose content the server has verified, or serve user files from a separate domain. An SVG is an image too, but it can carry script, so it gets the same treatment as HTML.

• Type: a harmless text file renamed .jpg; an image sent with Content-Type text/html; a double extension photo.jpg.html; an uppercase .PHP. Expected: the final extension, compared without regard to case, is on the allow list and the content matches it; the declared type alone never decides.
• Size: exactly the limit, one byte over, an empty file. Expected: accepted; rejected with a clear message; rejected or handled as empty.
• Name: ../../qa-traversal-test.png, a path traversal attempt: if the server builds the storage path from the original name, each ../ climbs one folder up, out of the upload folder (the name is unique, so a defect creates a new file instead of overwriting one); a 300-character name, spaces, Arabic letters, %00 (an encoded null byte), a name that is only an extension. Expected: stored under a server-generated name; the original name is only displayed, encoded.
• Served back: open the returned URL. Expected: the correct Content-Type, nosniff, attachment or a separate origin; nothing runs.
• Storage and execution: ask where files land and whether that path is executable; if a text file with a .php or .aspx name is accepted at all, it must download as text, never execute.

Try it: MIME Type Lookup Try it: Content-Type Validator Try it: Special Character Dataset Generator

Worked example: a checkout with a single-use coupon

Requirement: "A customer adds items to the cart, may apply one coupon (single-use per customer, minimum order 200 SAR), pays through the payment provider and receives a confirmation. Stock is reduced when the order is confirmed." The requests are POST /cart/items, POST /cart/coupon, POST /orders (creates the order and returns the total), POST /orders/{id}/pay and POST /orders/{id}/confirm.

Model it as states first, Cart, Coupon applied, Awaiting payment, Paid and Confirmed, then derive one test per forbidden move, one per field the server must own, and the boundary values of each rule (199.99 and 200.00 for the minimum order, checked again when items are removed after the coupon). Each test has a clear oracle: the order's state and total after the call, read back with GET /orders/{id}, and the stock count.

#  Test                                         Expected
1  POST /orders/{id}/confirm before /pay        4xx; stays Awaiting payment
2  /pay with "total": 1.00 in the body          4xx or ignored; server total kept
3  /cart/coupon twice with the same code        second call 4xx; discount once
4  coupon on a 199.99 cart (minimum 200.00)     4xx; no discount
5  coupon on a 200.00 cart                      accepted; discount applied
6  coupon at 200.00, then an item removed       discount dropped, or /orders 4xx
7  /cart/items with "quantity": -1              4xx; cart unchanged
8  /confirm sent twice in parallel              one confirmation; stock reduced once
9  /pay on another customer's order             403 or 404 (access control)
10 coupon already used on an earlier order      4xx; no discount

Try it: State Transition Generator Try it: API Request Builder

Frequently asked questions

References

• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.
• OWASP Cheat Sheet Series: File UploadOWASP FoundationValidating uploaded files: extension and content-type checks, size limits, storage outside the web root, scanning.
• OWASP API Security Top 10 (2023)OWASP Foundation · 2023The ten most common API weaknesses: broken object-level authorization, broken authentication, unrestricted resource consumption and more.
• OWASP Top 10:2025OWASP Foundation · 2025The ten most critical web application security risks, with how to test for and prevent each.