Common abuse: negative quantity in cart
A user can submit a negative quantity in a cart to get a refund against another item's cost, effectively using the cart as a free money transfer. Validate that quantities are positive and at least 1.
OWASP Cheat Sheets · all subjects
abuse_cases/examples
32 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Common abuse: client-supplied price trusted by server
Server accepts and trusts a price field from the client request instead of looking it up from the product database. An attacker sets the price to a very low value like one cent and completes purchase.
Common abuse: zero-price items misapplied
Zero-price items that are actually valuable because a free flag was intended for a different product. An attacker manipulates which product the free flag applies to and receives expensive items at no cost.
Common abuse: currency switching mid-transaction
Amount is specified in one currency but processed in another much weaker currency, keeping the numeric amount the same. An attacker switches from USD to a currency with much lower value and completes transaction at artificially low cost.
Common abuse: coupon codes applied multiple times
Coupon codes can be redeemed by the same user multiple times, or applied to products they were not intended for, stacking discounts. Enforce single-use per user and product category restrictions.
Common abuse: skip identity verification by direct endpoint call
Multi-step workflow skips identity verification step by calling the post-verification endpoint directly, bypassing the verification that was supposed to gate access.
Common abuse: advance workflow past gated reviewer step
Application or KYC workflow advances past a stage that was supposed to be gated on a reviewer's approval, either by calling the next-step endpoint directly or by not checking reviewer status.
Common abuse: trigger checkout complete without payment
Checkout endpoint completes without actually verifying that payment was processed. An attacker calls the post-payment endpoint directly and receives order without paying.
Common abuse: concurrently withdraw same balance twice
Two concurrent withdrawal requests from the same account both pass the balance check before either debit executes, allowing total withdrawals to exceed the available balance.
Common abuse: redeem single-use voucher from concurrent requests
A single-use voucher is redeemed by two parallel requests because neither request locked the voucher before checking or marking it redeemed.
Common abuse: approve own request due to missing author check
User approves their own request because the is-not-author check was forgotten from the authorization logic. Every approval operation must verify the approver is not the requester.
Common abuse: signup bonus claimed multiple times
User claims a signup bonus multiple times by re-signing up or by replaying the bonus-claim request. Once a one-time bonus is granted, mark it complete and reject replays.
Common abuse: self-referral to earn referral rewards
User refers themselves using a second account to earn referral rewards. Referral flows should check that referrer and referee are distinguishable humans based on device, IP, payment method or other identity signals, not just distinguishable accounts.
Common abuse: stack mutually exclusive promos
Multiple promos that were each meant to be used alone are combined to push a price below cost. If a coupon engine allows stacking by default, it is probably a bug. Explicitly enforce mutual exclusivity on promos.
GraphQL batching attack: definition
GraphQL supports batching requests, also known as query batching. This lets callers batch multiple queries or batch requests for multiple object instances in a single network call. A batching attack is a form of brute force attack specific to GraphQL that usually allows for faster and less detectable exploits. Batched requests can be formatted as an array of objects, where each object contains a query and variables.
GraphQL batching attack: impacts
GraphQL batching attacks can lead to: (1) Application-level DoS attacks where a high number of queries or object requests in a single network call could cause a database to hang or exhaust resources like memory, CPU, or downstream services. (2) Enumeration of objects on the server such as users, emails, and user IDs. (3) Brute forcing passwords, 2 factor authentication codes (OTPs), session tokens, or other sensitive values. (4) WAFs, RASPs, IDS/IPS, SIEMs, or other security tooling will likely not detect these attacks since they only appear to be one single request. (5) The attack will likely bypass existing rate limits in tools like Nginx or other proxies or gateways since they rely on looking at the raw number of requests.
IDOR example with numeric URL identifier
An IDOR vulnerability occurs when an attacker can change a numeric identifier in a URL to access another user's data. For example, accessing https://example.org/users/123 allows the attacker to change 123 to 124 to view user 124's information if the application does not verify whether the user has permission to access that data.
IDOR in POST body with hidden field
IDOR vulnerabilities can exist in POST request bodies, not just URLs. An application might include a user_id in a hidden form field. If the server does not perform proper access control checks, attackers can manipulate the user_id field to modify profiles or data of other users without authorization.
Mass Assignment GitHub 2012 breach case study
In 2012, GitHub was hacked using mass assignment. A user was able to upload their public key to any organization and make any subsequent changes in their repositories, demonstrating the real-world impact of this vulnerability.
Always log suspicious business logic activities
Suspicious business logic activities must always be logged, including: attempts to perform a set of actions out of order or bypass flow control; actions which do not make sense in the business context; attempts to exceed limitations for particular actions.
Session cookies scoped to parent domain can be stolen via subdomain takeover
If session cookies are scoped to the parent domain (e.g., `.example.com`), an attacker controlling a subdomain (e.g., `attacker-controlled.example.com`) will receive those cookies in requests, enabling session hijacking.
Subdomain takeover enables bypassing Content Security Policy wildcard rules
An attacker controlling a taken-over subdomain can bypass Content Security Policy rules that trust wildcard subdomains (`*.example.com`), allowing injection of malicious scripts or exfiltration of data.
Subdomain takeover enables phishing and OAuth/SSO compromise
An attacker controlling a subdomain can host convincing phishing pages on a domain already trusted by the organization's users and customers. If the subdomain is whitelisted as a valid redirect URI in OAuth and SSO flows, the attacker can steal tokens and compromise authentication.
MX record takeover enables email interception and TLS certificate issuance
If MX records point to a deprovisioned mail service, an attacker controlling those records can intercept email for the subdomain. Most Certificate Authorities accept email-based domain validation using addresses like `admin@subdomain.example.com`. An attacker can complete DV challenges and obtain legitimate TLS certificates, enabling transparent HTTPS phishing or man-in-the-middle attacks.
SPF records and subdomain takeover risk
If SPF records include mechanisms that match the taken-over subdomain's IP, the attacker can send SPF-authenticated email appearing to originate from your domain.
Spring STOMP WebSocket RCE CVE-2018-1270
Spring had an RCE vulnerability (CVE-2018-1270) that let attackers execute code through crafted STOMP messages on WebSocket connections.
ID attribute focus/blur XS Leak attack
An attacker can embed a victim's application in an iframe and exploit the browser's automatic focus behavior on elements with matching hash IDs. When a URL like https://example.com#pro is loaded, the browser focuses on the element with id="pro" and fires a focus event. The attacker listens for the blur event (the opposite of focus) on their page. If the blur event fires, the attacker can infer that the element exists in the application (e.g., the user has a pro account).
Error event XS Leak attack via resource loading
An attacker can embed resources from other origins (images, scripts) on their page and observe HTTP response status codes through onload and onerror JavaScript events. For example, loading GET /api/user/1234 returns 200 OK (onload event fires), while GET /api/user/1235 returns 401 Unauthorized (onerror event fires). By enumerating values in a loop, an attacker can guess information like the victim's user ID. The attacker does not need to read the response body due to browser isolation mechanisms like Cross-Origin Resource Blocking (CORB).
Frame counting XS Leak attack
An attacker can obtain information about the number of loaded frames in a window by counting frames in the window.frames object. For applications that load search results into frames where empty results cause no frame to load, an attacker can enumerate a list (such as emails) by opening windows and counting frames. If window.frames.length equals 1, the searched value is in the victim's database.
Browser cache timing XS Leak attack
An attacker can detect whether a resource was loaded from browser cache by measuring load time via JavaScript. Resources loaded from cache memory load significantly faster than from the server. By embedding a resource that is only accessible to users with admin role and reading the load time using window.performance.getEntries(), an attacker can deduce whether the resource is cached. If load time is below a threshold, the resource was cached, indicating the user previously accessed the admin page.
postMessage XS Leak attack example
An attacker controls a page at https://evil.com. A victim's site at http://example.com opens a popup to evil.com and sends a postMessage with a secret: popup.postMessage('secret message!', '*'). The attacker's evil.com page listens for messages with window.addEventListener('message', e => alert(e.data)) and receives 'secret message!' because the wildcard targetOrigin '*' permits any origin to receive the message.
Insecure documentation examples: weak key derivation, credential exposure, regex anchoring, randomness
Real-world documentation vulnerabilities found in popular npm packages include: weak key derivation using MD5 with single iteration (EVP_BytesToKey) in AES README examples instead of the library's own PBKDF2 module; credential exposure on redirect via beforeRedirect callbacks that re-inject authorization headers after protocol downgrades; unanchored regex patterns (e.g., '/example\.com/') for JWT audience or CORS origin validation that match subdomains like 'malicious-example.com' instead of using '^https:\/\/example\.com$'; insecure randomness using Math.random() in file upload examples instead of the library's crypto.randomBytes(16).