DEV Community: Excession Labs

Race condition vulnerability in a single-use coupon endpoint

Vladimir Osipov — Wed, 11 Nov 2026 01:18:27 +0000

Race condition vulnerability in a single-use coupon endpoint

We reproduced a race condition vulnerability in a single-use coupon endpoint running on Python's threaded HTTP server. Widening the gap between the check and the write made sixteen concurrent redemption attempts against one coupon succeed sixteen times out of sixteen, every round. With no added delay the same flaw still let through extra redemptions on three of five rounds, with 3, 8 and 4 successes. A single conditional SQL update closed the gap and held at exactly one success across every retest.

This is a scripted Python and curl experiment with downloadable source and responses. The sixteen concurrent requests were sent with Python threads calling the standard library's urllib, not curl --parallel; curl sent the sequential control requests. No AI agent or model ran the test.

On this page: Scope · Reproduce the run · Observed results · Verify the finding · Fix and retest · Limits

Define the race condition vulnerability and test scope

A race condition vulnerability appears when a server checks a condition, then acts on that check, and a second request changes the underlying state somewhere in between. The two steps are not one operation, so correctness depends on no other request landing in the gap. Our fixture issues a coupon, SAVE10, with exactly one use. The rule is that one redemption request should succeed and every other concurrent request should receive a 409.

This fixture demonstrates CWE-367, Time-of-check Time-of-use (TOCTOU) Race Condition, a specific case of the broader CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization. A race condition attack against a coupon, a credit balance, or an inventory count is sometimes described as a double spend, after the same failure mode in payment systems: two requests both pass a check that was only ever supposed to let one through.

Target: one HTTP server built on http.server.ThreadingHTTPServer, bound to IPv4 loopback, 127.0.0.1. Each connection runs on its own thread, the same model many small Python services use. The runner selects free ports.
Allowed requests: POST /redeem with a coupon code header, and GET /status to read a coupon's remaining uses.
Coupons: SAVE10 for the concurrent burst, and a separate CONTROL1 used only for a sequential positive and negative control. Both are fixed synthetic demo codes.
Data: a temporary on-disk SQLite file created fresh per server process and removed on shutdown. There are no customer records or external services.

The fixture is intentionally insecure in its vulnerable mode and has no configurable bind address; it always listens on loopback. For a staging engagement, agree the hosts, accounts, records and stopping conditions with the system owner before replacing this scope. The Excession Labs Acceptable Use Policy describes authorized use. This article gives no permission to test another system.

Run the downloadable fixture

Download fixture.py and verify.py into the same directory. You need Python 3.9 or later and curl; the Python code uses only the standard library. Inspect the source, then run:

python3 verify.py --output rerun

The output directory must be new. The runner starts a fresh fixture process for each of three conditions, five times each: vulnerable-baseline (no added delay), vulnerable-widened (a stated 50 ms sleep inserted between the check and the write), and fixed (one conditional UPDATE, no separate check step at all). Each round runs a negative control, a sequential positive and negative control on CONTROL1, a burst of sixteen simultaneous redemption attempts on SAVE10, and a final read of the coupon's remaining uses, then stops the server.

Our recorded command was python3 verify.py --output recorded-run. It exited successfully, having run fifteen rounds with no failed controls and exactly one success in every fixed round. The run on 10 November 2026 used fixture and runner version 1.0.0, Python 3.15.2 and curl 8.7.1 on macOS ARM64. Exact runtime strings, UTC timestamps, every command, every round's raw counts and source SHA-256 hashes are in results.json. A rerun will use different ports, timestamps and, because this is a race, a different spread of outcomes in the unfixed modes.

Observed results: how many redemptions actually succeeded

The single-use policy says one of the sixteen concurrent requests per round should succeed. The recorded run produced these counts. Each round used a fresh server and a fresh coupon:

Successful redemptions out of 16 concurrent requests, by round

Condition	Added check-to-write delay	Round 1	Round 2	Round 3	Round 4	Round 5	Policy expects
vulnerable-baseline	none	3	1	8	1	4	1
vulnerable-widened	50 ms	16	16	16	16	16	1
fixed	n/a	1	1	1	1	1	1

Two rounds of the unwidened baseline landed on exactly one success, the correct outcome, by chance. An unwidened race on one laptop does not fail every time. With a stated 50 millisecond sleep between the read and the write, all sixteen requests succeeded in each of the five rounds. The fixed condition held at exactly one success in all five rounds with no added delay at all, because it has no window for a second request to land in.

The sequential controls on CONTROL1 passed in every round and every condition, including the vulnerable ones: a solo first redemption returned 200, a solo second redemption returned 409. The flaw appears only under concurrency.

Verify the finding before reporting it

In the recorded first round of the widened condition, the server reported uses_remaining: -15 after the burst, on port 56808. This is the final status check, reformatted across lines:

curl --noproxy '*' --silent --show-error --include \
  --http1.1 --connect-timeout 1 --max-time 3 --request GET \
  'http://127.0.0.1:56808/status?code=SAVE10'

The recorded response:

HTTP/1.0 200 OK

{"code": "SAVE10", "uses_remaining": -15}

A negative remaining count is strong evidence on its own: the counter started at one, and ending at negative fifteen means sixteen decrements were applied to a coupon that was supposed to allow exactly one. results.json also records each of the sixteen individual responses, their status codes and bodies, so the finding does not rest on the counter alone. A weaker form of this evidence would be sixteen 200 responses with no record of the final state, since a server could return 200 before actually writing anything.

A useful finding records the endpoint, the shared resource, the check and the write it should have been one operation, the number of concurrent requests sent, how many succeeded against how many should have, and the resulting state of the resource. Here the impact is one coupon consumed sixteen times instead of once. This experiment does not establish a production severity rating; that depends on what the coupon is worth and whether the application has any other backstop, such as a reconciliation job.

Fix: an atomic check-and-update, and retest

The same fixture source has two code paths. In vulnerable mode, the handler reads the row, sleeps, then writes a separate decrement:

row = check_conn.execute(
    "SELECT uses_remaining FROM coupons WHERE code = ?", (code,)
).fetchone()
remaining = row[0]
if remaining <= 0:
    return self.reply(409, {"error": "coupon_exhausted"})
time.sleep(delay)
write_conn.execute(
    "UPDATE coupons SET uses_remaining = uses_remaining - 1 WHERE code = ?", (code,)
)

Fixed mode replaces both statements with one conditional update that is itself the check:

cur = conn.execute(
    "UPDATE coupons SET uses_remaining = uses_remaining - 1 "
    "WHERE code = ? AND uses_remaining > 0",
    (code,),
)
if cur.rowcount == 1:
    return self.reply(200, {"status": "redeemed", "code": code})

There is no read step to race against, because the condition and the write happen inside the same statement. SQLite's documentation on transactions says that any SQL command that is not already inside a BEGIN automatically starts an implicit transaction, which commits when that statement finishes. SQLite allows one writer per database at a time. A second connection's UPDATE waits, up to the 5 second busy timeout, for the first to commit, then evaluates uses_remaining > 0 against the new value. Other databases give the same guarantee for a single conditional UPDATE through row locks. If the data lives in the memory of one process, a lock held across the check and the write also closes the gap. A lock does not help when several processes or hosts serve the endpoint.

The runner reran the full sequence against fixed mode for five fresh rounds, each with a new database and a new coupon. Every round produced exactly one 200 and fifteen 409 responses, and the final status check returned uses_remaining: 0 each time, never negative. The sequential controls on CONTROL1 still passed, so the fix did not block the legitimate single redemption it was meant to allow.

Inspect the evidence bundle

Machine-readable results: all fifteen rounds, every one of the sixteen burst responses per round, expected and observed outcomes, and source hashes.
Exact recorded commands: the curl invocations and the fixture startup command for every round. Ports were ephemeral and are no longer listening.
SHA-256 manifest: compare downloaded sources and evidence. This is an integrity check, not independent attestation.
Fixture instructions and limitations, server source and verification source.

All coupon codes and the data they touch are synthetic public demo values. The bundle includes the actual recorded HTTP response text for a representative round of each condition, in addition to the summary counts quoted above.

What this experiment does not cover

Sixteen threads against one in-process SQLite file on one laptop show one check-then-act window closing under one fix. We did not test a real production database under production-scale concurrent load, where lock contention and connection pooling behave differently than a temp file does. We did not test a distributed system where the check and the write happen on different hosts, a file-system race such as a symlink swap. We did not test races inside authorization checks.

For a real engagement, identify every check-then-act sequence that touches a limited resource, such as a rate limit, a one-time code, or a stock count, and test each with concurrency that matches production traffic rather than sixteen threads on one laptop. Keep the unfixed baseline's results alongside the fixed retest, including rounds where the race happened not to trigger. Related categories worth reviewing on the same system include API rate limiting, broken access control, and the OWASP API Top 10 as a whole.

Excession Labs tests for race condition vulnerabilities as part of its security assessments. See how a finding like this looks in a sample report.

Originally published at https://excessionlabs.ai/blog/race-condition/ . The test code and recorded output are there.

SQL injection example: login bypass and UNION reads on a local API

Vladimir Osipov — Wed, 11 Nov 2026 01:12:23 +0000

SQL injection example: login bypass and UNION reads on a local API

SQL injection happens when an application pastes request data into the text of a query, so the input can change what the query means. In a small sqlite3-backed HTTP API we bypassed a login with one crafted username and read every user's password hash through a search parameter. Binding values with placeholders stopped both attacks, but a sort parameter still leaked data until we replaced it with an allowlist.

This is a scripted Python and curl experiment with downloadable source and responses. No AI agent or model ran the test.

On this page: Definition and scope · Reproduce the run · Observed results · The attacks · Verify a finding · Fix and retest · What parameters do not cover · Evidence · Limits

What SQL injection is and what the fixture covers

SQL injection is a flaw where untrusted input becomes part of the SQL statement instead of staying a value. MITRE lists it as CWE-89, Improper Neutralization of Special Elements used in an SQL Command. The OWASP SQL Injection Prevention Cheat Sheet names parameterized queries as the preferred defense, and it says parts of a query that cannot be parameterized, such as table names, column names and sort direction, should be mapped to a strict allowlist of fixed values the application owns.

The fixture is one Python file with an in-memory sqlite3 database and four endpoints on 127.0.0.1. It has three modes so each defense can be tested alone:

vulnerable: every query is built by string concatenation.
bound: values use ? placeholders, but the sort parameter is still concatenated into ORDER BY.
fixed: values use placeholders and sort must match an allowlist.

Endpoints are POST /login, GET /search (with q and sort), POST /register and GET /history. The data is synthetic: three users (alice, bob and o'brien), four products and three orders. Demo passwords are public test strings, and the fixture stores unsalted SHA-256 hashes for brevity, which is not a model for real password storage. The fixture is insecure on purpose and always binds loopback. Test only systems you own or have written permission to test; the Acceptable Use Policy describes authorized use, and this article gives no permission to test anything else.

Run the downloadable fixture

Download fixture.py and verify.py into one directory. You need Python 3.9 or later and curl. Python uses only the standard library. Then run:

python3 verify.py --output rerun

The output directory must not exist. The runner starts each mode on a free port, sends 14 real curl requests to it, saves every raw response, and stops the server. Requests bypass proxies, time out after three seconds and never leave loopback.

Our recorded command was python3 verify.py --output recorded-run. It printed {"checks": 42, "passed": true, "failures": []}. That result means all 42 responses matched what we expected, including the unsafe ones. It does not mean the vulnerable mode is safe. The run started at 22:46:49 UTC on 10 November 2026 with Python 3.15.2, SQLite 3.54.1 and curl 8.7.1 on macOS ARM64. Ports, timestamps and response dates differ on a rerun. results.json holds the exact versions and source hashes.

Observed results across three modes

Each row is one test. The vulnerable column is the unsafe baseline, the bound column shows what placeholders alone give you, and the fixed column adds the sort allowlist. Legitimate requests appear as controls so a server that rejects everything cannot pass.

Observed responses from 42 local requests

Test	Safe server should return	vulnerable	bound	fixed
Login, right password	200 as alice	200	200	200
Login, wrong password	401	401	401	401
Login as o'brien, right password	200	500	200	200
Login as `alice'--`, wrong password	401	200 as alice	401	401
Search `Widget`	200, two rows	200, two rows	200, two rows	200, two rows
Search with UNION payload	200, no rows	200, 3 user rows with hashes	200, no rows	200, no rows
Sort by `price`	200, ids 4,1,3,2	200, ids 4,1,3,2	200, ids 4,1,3,2	200, ids 4,1,3,2
Sort by `nosuchcolumn`	400	500	500	400
Sort expression, true condition	400	200, ids 4,1,3,2	200, ids 4,1,3,2	400
Sort expression, false condition	400	200, ids 2,3,1,4	200, ids 2,3,1,4	400
Register `carol`, read history	201, then her one order	201, one order	201, one order	201, one order
Register `x' OR '1'='1`, read history	201, then no orders	201, then all 3 orders	201, no orders	201, no orders

Login bypass, UNION read and second-order injection

The vulnerable login builds its query like this:

sql = "SELECT username FROM users WHERE username = '" + username + "' AND pw_hash = '" + pw_hash + "'"

With the username alice'-- the text becomes ... WHERE username = 'alice'--' AND pw_hash = '...'. The -- starts a SQL comment, so the password test disappears. The server answered {"ok": true, "user": "alice"} to a request with the password wrong. The same fixture returned a 500 for the legitimate user o'brien, because his apostrophe closed the string early. An unexplained 500 on a name with an apostrophe is a common first sign of this flaw.

The search endpoint builds name LIKE '% + q + %'. A UNION payload in q appends a second SELECT from another table with the same column count:

curl --get --data-urlencode "q=zzz' UNION SELECT id, username, pw_hash FROM users --" \
  http://127.0.0.1:53155/search

The recorded response listed alice, bob and o'brien in the name field with their SHA-256 hashes in the price field. The authorization checks around an endpoint do not help here, because the query itself reads data the endpoint was never meant to touch.

Second-order SQL injection stores the payload first and triggers it later. In the fixture, /register inserts the username with placeholders, so registering x' OR '1'='1 succeeds with a 201. Later, /history reads the stored name back and concatenates it into an orders query, on the assumption that data from its own database is safe. In vulnerable mode that request returned the orders of alice, bob and carol. The bug sits in the second query, even though the first one looked clean.

Verify a SQL injection finding before you report it

A single odd error is only a lead. A finding needs a controlled difference. For the login bypass, send three requests: the right password, a wrong password, and the injected username with the same wrong password. A bypass is verified when only the injected request succeeds and the response identifies the user. For the UNION read, check that the returned values come from the other table, here the hashes in price. Record the endpoint, parameter, payload, request, response and the data class exposed. Stop after proving access. Do not dump a real table to show impact.

This experiment shows the flaw in a toy. It gives no severity rating for a production system, and a 500 alone does not prove injection.

Parameterize the queries and retest

The fix for values is to keep the SQL text fixed and pass data separately. This is the login query in bound and fixed mode:

row = db.execute("SELECT username FROM users WHERE username = ? AND pw_hash = ?",
                 (username, pw_hash)).fetchone()

The search value and the history query use the same placeholder style. The retest used the same 14 requests against fresh servers on ports 53170 and 53186. alice'-- returned 401, the UNION payload returned an empty result list, o'brien logged in with a 200, and the stored payload matched no orders. The positive controls still passed: alice's correct login, the Widget search and carol's history all returned the same data as before.

What parameters do not cover: ORDER BY and other identifiers

Placeholders bind values. They cannot stand in for a column name, a table name or a sort direction, so developers often concatenate those. Our bound mode concatenates sort this way, and it still failed. Sorting by nosuchcolumn returned a 500, which shows the input reaches the parser. Two expressions then showed that the order of the results can carry one yes-or-no answer per request:

sort=CASE WHEN (SELECT substr(pw_hash,1,1) FROM users WHERE username='alice')='4'
     THEN price ELSE -price END

When the first character of alice's hash matched, ids came back as 4,1,3,2. With a wrong character they came back as 2,3,1,4. We ran one true and one false probe and did not extract a whole hash, but the channel works in both vulnerable and bound modes. In fixed mode the server looks up the requested name in a dictionary:

if sort not in SORT_COLUMNS:
    return self.reply(400, {"error": "invalid_sort"})
sort = SORT_COLUMNS[sort]

Both probes and the unknown column returned 400 in fixed mode, and sort=price still returned 200. This matches the OWASP guidance to map user choices to fixed application-owned values. Quoting an identifier is a weaker option, because it only controls syntax and does not restrict which columns a caller can name.

Inspect the evidence bundle

results.json: all 42 requests with commands, expected and observed values, and hashes.
commands.sh: the exact curl commands. Their ports are no longer listening.
SHA256SUMS: an integrity check, not independent attestation.
README.txt, fixture.py and verify.py.

The folder also holds one raw .http file per request, for example the vulnerable login bypass and the fixed-mode rejection of an unknown sort column. All data is synthetic.

What this experiment does not cover

We tested one database engine and one request style. We did not test blind or time-based techniques, out-of-band channels, stacked statements, ORMs, stored procedures, JSON or XML inputs, other SQL dialects, database account privileges or a web application firewall. The OWASP cheat sheet also recommends least-privilege database accounts as a second layer. The fixture does not model that. Passing the fixed mode shows that these 14 requests no longer misbehave. It says nothing about other queries in an unrelated codebase.

For related reading, see how path traversal abuses a different untrusted input, and the OWASP API Top 10 for a test list per API risk. The 2023 API list has no separate injection category.

Excession Labs runs this kind of injection testing in its security assessments, using test accounts and synthetic records to confirm each finding. See how a finding like this looks in a sample report. Download this finding written up as a one-page sample report (PDF).

Originally published at https://excessionlabs.ai/blog/sql-injection/ . The test code and recorded output are there.

IDOR vulnerability: a local example with PUT and DELETE

Vladimir Osipov — Wed, 11 Nov 2026 01:11:28 +0000

IDOR vulnerability: a local example with PUT and DELETE

An IDOR vulnerability (insecure direct object reference) lets a signed-in user act on another user's record by sending that record's ID. In a small local invoices API, a second user listed, edited and deleted the first user's invoices. Replacing numeric IDs with UUIDs did not stop the attack, because a list endpoint returned every ID. An ownership check on each method stopped all of it.

This is a scripted Python and curl experiment with downloadable source and responses. No AI agent or model ran the test.

On this page: What it is · Scope · Reproduce the run · Observed results · UUIDs · Verify the finding · Fix and retest · Evidence · Limits

What an IDOR vulnerability is

The OWASP IDOR Prevention Cheat Sheet defines IDOR as a flaw that arises when attackers can access or modify objects by manipulating identifiers in URLs or parameters. It lists three ingredients: an object, a reference to it (an ID, UUID, account number, token or slug), and a missing object-level authorization check.

CWE-639, Authorization Bypass Through User-Controlled Key, describes the same weakness: the authorization logic does not stop one user from reaching another user's data by changing the key that identifies it. OWASP's API list files it as API1:2023, Broken Object Level Authorization, and notes that object IDs can be sequential integers, UUIDs or strings.

Our earlier post on API authorization testing shows a cross-account read. This post adds enumeration, changes with PUT, removal with DELETE, and the effect of switching to UUIDs.

Scope of the fixture

The fixture is an invoices API with three synthetic invoices. Alice owns 1001 and 1002. Bob owns 1003. The policy is that each user may list, read, update and delete only their own invoices.

Target: short-lived HTTP servers on 127.0.0.1, started on free ports by the runner. The server has no option to bind elsewhere.
Methods: GET /invoices, GET /invoices/{id}, PUT /invoices/{id} and DELETE /invoices/{id}.
Identities: the public demo bearer values demo-alice-token and demo-bob-token.
Configurations: numeric or UUID IDs, each with the ownership check off or on. That gives four servers and 16 requests per server.

The vulnerable configurations omit the ownership check on purpose. In both of them the list endpoint returns every invoice without filtering by caller. For testing a real system, agree hosts, accounts, records, methods and stopping conditions with its owner first. The Acceptable Use Policy describes authorized use, and this article gives no permission to test any other system.

Run the downloadable fixture

Download fixture.py and verify.py into one directory. You need Python 3.9 or later (standard library only) and curl. Run:

python3 verify.py --output rerun

The output directory must be new. Every curl call bypasses proxies, has a one-second connect timeout and a three-second total timeout, and follows no redirects.

Our recorded command was python3 verify.py --output recorded-run. It printed {"checks": 64, "passed": true, "failures": [], "policy_violations_observed": 16} and exited with status 0. That line means every response matched what the fixture was built to produce, including the vulnerable ones. The 16 policy violations are the reproduced IDOR behavior. The run took place on 10 November 2026 with Python 3.15.2 and curl 8.7.1 on macOS ARM64. results.json holds the exact versions, timestamps, commands and source hashes.

Observed results for the IDOR example

Each server started fresh. Bob first listed invoices. He then requested Alice's invoices by ID, changed one with PUT, and deleted the other. Alice re-read both invoices afterwards to see what the server stored. The IDs Bob used came from his own list response whenever it contained them.

In the sequential configuration, Bob did not need the list at all. Numeric guesses for 1001 and 1002 returned 200 with Alice's invoices, and 1004 returned 404, which tells an attacker where the sequence ends. Bob's PUT set Alice's invoice to amount_cents 1 and status paid. His DELETE removed 1002, and Alice's next read of it returned 404.

Four controls ran in every configuration and behaved the same each time. Alice read her own invoice (200). Alice updated her own invoice (200). Bob deleted his own invoice (200), after which a read returned 404. An anonymous request returned 401. A server that rejected everything would pass the attack rows and fail these, so the controls show that the fix leaves legitimate use working.

Why UUIDs alone do not fix an IDOR vulnerability

OWASP's API1 prevention advice says to prefer random, unpredictable values as record IDs, and the cheat sheet adds that complex identifiers such as GUIDs can make valid values practically impossible to guess, but that access control checks are essential even then. In our run, Bob's numeric guesses against the UUID servers returned 404 for all three IDs, so blind enumeration stopped working.

The unfiltered list endpoint gave the IDs away. Bob's GET /invoices on the UUID server returned three invoices, including both of Alice's with their UUIDs. Bob then read, changed and deleted them. The attack needed one extra request. The same applies to any place an ID can surface to another user: a shared link, an email, a log line, an export or a support ticket.

A random ID makes a valid reference harder to find. The server still needs an ownership check to decide whether the caller may use it.

Verify the finding before you report it

A 200 from a PUT shows that the server accepted the request. It does not prove that another account's data changed. Confirm each write or delete by reading the object back as its owner. This is the exact command from the recorded sequential run, split across lines:

curl --noproxy '*' --silent --show-error --include \
  --http1.1 --connect-timeout 1 --max-time 3 --request PUT \
  --header 'Authorization: Bearer demo-bob-token' \
  --header 'Content-Type: application/json' \
  --data '{"amount_cents": 1, "status": "paid"}' \
  http://127.0.0.1:52911/invoices/1001

The recorded response was 200 with "owner": "alice" and "amount_cents": 1. Alice's follow-up GET returned the same changed values, which shows that the write persisted under the real owner's account. For DELETE, the matching evidence is Alice's 404 on an invoice that the policy says she still owns.

A report should name the method and path, the acting identity, the object owner, the policy that was expected, the observed status and the changed or disclosed fields. It should also record the controls that passed. The impact here is limited to synthetic invoices. This experiment cannot rate severity for a real system.

The fix: one ownership check on every method

All three object methods in the fixture call one function. In the fixed configurations it compares the invoice's owner with the authenticated identity before any read, update or delete happens:

def fetch(self, identity, invoice_id):
    invoice = self.server.invoices.get(invoice_id)
    if invoice is None:
        self.reply(404, {"error": "not_found"})
        return None
    if self.server.authz == "owner" and invoice["owner"] != identity:
        self.reply(403, {"error": "forbidden"})
        return None
    return invoice

The list endpoint needs the same rule, applied as a filter:

rows = [i for i in self.server.invoices.values()
        if self.server.authz != "owner" or i["owner"] == identity]

Because every method goes through one function, PUT and DELETE get the same check as GET. A check added only to GET would leave them open. The check also has to run on the server for every request, whatever the client UI shows.

The retest used the same requests. With the check on, Bob's list returned one invoice, his GET, PUT and DELETE on Alice's invoices returned 403, and Alice's follow-up reads showed the original amount, 12500, and her second invoice intact. This held with numeric IDs and with UUIDs. Numeric guesses for Alice's IDs returned 403 on the sequential server and 404 on the UUID server. All four controls still passed. This check works for a model where each invoice has one owner. Shared invoices, roles and tenant hierarchies need a richer policy, as in tenant isolation.

Evidence bundle

results.json: all 64 cases with identities, expected and observed statuses, bodies and response hashes.
commands.sh: the exact curl commands. The ports belong to the finished run.
SHA256SUMS: an integrity check on the published files, not independent attestation.
README.txt, fixture.py and verify.py.

All tokens, names and invoices are synthetic. The bundle contains the full HTTP responses, including dates and server headers.

What this experiment does not cover

The fixture is a toy with one owner per object. It shows that a missing ownership check allows read, write and delete across accounts, and that UUIDs do not compensate for it. It does not show how common this is, how severe it is elsewhere, or that the fixed server is secure in any wider sense.

We did not test PATCH, bulk or batch endpoints, nested resources, IDs in request bodies or query strings, GraphQL, shared objects, role changes, caching, or races between a check and a write. Our UUID guesses were numeric strings. We did not try to guess real UUIDs. The 403 on an existing object also confirms that the object exists; some APIs return 404 for both cases to avoid that. For a broader view of the class, see broken access control and the OWASP API Top 10.

Excession Labs runs this kind of object-level test, with two accounts and every method, in its security assessments. See how a finding like this looks in a sample report. Download this finding written up as a one-page sample report (PDF).

Originally published at https://excessionlabs.ai/blog/idor-vulnerability/ . The test code and recorded output are there.