Notifications
Clear all
Topic starter
11/08/2026 3:21 pm
TL;DR: Two newly disclosed Spree IDORs show that autonomous traces can move beyond parameter fuzzing and surface object-level authorization failures hidden in business logic, according to Xbow Security Research. The real shift is that access-control assumptions built for static scanners are now being tested by systems that can reason across objects, states, and fallback paths.
NHIMG editorial — based on content published by Xbow: Tales From the Trace, how XBOW reasons its way into finding IDORs
By the numbers:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps , 38% have no or low visibility, and a further 47% have only partial visibility.
Questions worth separating out
Q: What breaks when object-level authorisation is missing in web applications?
A: The application may let a valid session read or modify records that belong to someone else.
Q: Why do IDOR flaws persist in modern applications?
A: They persist because they are design and business-logic failures, not obvious syntax errors.
Q: How do security teams test for IDOR effectively?
A: They should create multiple identities, generate separate objects for each one, and replay the same requests across roles, sessions, and workflow stages.
Practitioner guidance
- Map every object reference to an entitlement check Inventory APIs and UI flows where one object points to another, such as address IDs, order IDs, and profile records.
- Test authenticated and unauthenticated states separately Run the same object access tests with and without session cookies, then compare response codes, returned fields, and prefilled values.
- Add cross-object access cases to DAST and QA Build test cases that try foreign object IDs inside legitimate sessions, especially where checkout, billing, and profile data are linked.
What's in the full article
Xbow’s full security research covers the operational detail this post intentionally leaves for the source:
- Trace-by-trace breakdown of how the autonomous tester reasoned through each Spree endpoint
- Raw request and response evidence showing the address and checkout object joins that failed
- Step-by-step disclosure context for the two newly patched vulnerabilities in Spree v5.2.5
- The exact object references and payload structure used during the multi-cart validation
👉 Read Xbow’s security research on autonomous reasoning and Spree IDOR findings →
AI pentesting and IDORs: what does autonomous testing change?
Explore further
11/08/2026 3:32 pm
Object-level authorisation is the real control boundary in modern web applications. Login success does not prove entitlement to a record, and role membership alone does not protect nested objects. The Spree findings show that APIs can still leak personal data when session authority is not revalidated at the object layer. Practitioners should treat every linked identifier as a separate access decision.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to NHI Mgmt Group research.
A question worth separating out:
Q: Who is accountable when object references expose another user’s data?
A: Accountability is shared across application owners, IAM teams, and security engineering because the failure sits at the join between identity, workflow design, and data access. Controls like access review, secure code review, and runtime authorisation testing all matter, but the owning team must prove object-level entitlement.
👉 Read our full editorial: Autonomous reasoning is exposing IDOR gaps in mature web apps
