Notifications
Clear all
Topic starter
18/08/2026 2:38 pm
TL;DR: IDOR flaws slip past DAST because the requests look valid and the failure is in ownership enforcement, not input syntax, according to Apiiro. The practical lesson is that authorization testing must combine identity, architecture, and runtime context, because point-in-time scanning cannot reliably expose logic bugs that change with deployment cycles.
NHIMG editorial — based on content published by Apiiro: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- The 2025 Verizon DBIR found that vulnerability exploitation as an initial breach vector grew 34% year over year, now accounting for 20% of confirmed breaches.
- In bug bounty programs, IDOR accounts for roughly 15% of retail bounties and up to 36% in medtech.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
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.
Q: Why do valid requests still create authorization risk?
A: A request can be syntactically correct and still be unsafe if the application does not verify who owns the object or whether the caller is entitled to the action.
Q: What do teams get wrong about DAST and authorization testing?
A: Teams often assume DAST can validate access control because it can reach the endpoint and see a successful response.
Practitioner guidance
- Implement two-identity authorization tests Build test cases that request the same object from two authenticated users and verify that ownership is enforced at the API or service layer.
- Map object ownership to identity context Document which user, role, tenant, or service account is allowed to read or mutate each object type, then compare that map to actual application behaviour.
- Prioritise context-rich findings over raw alerts Score authorization findings by public reachability, data sensitivity, and workflow depth so teams can focus on exploitable paths instead of the largest alert volume.
What's in the full article
Apiiro's full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step breakdown of how DAST coverage fails against valid-looking object references in API and GraphQL flows.
- Examples of where authorization logic breaks in multi-step workflows, bulk actions, and secondary application paths.
- Runtime and AI-assisted detection patterns for separating true ownership flaws from false positives.
- The article's own discussion of how to prioritise IDOR findings by reachability and business impact.
👉 Read Apiiro's analysis of why DAST misses IDOR authorization flaws →
IDOR authorization gaps: why scanners miss legitimate-looking abuse?
Explore further
18/08/2026 3:22 pm
IDOR is not a scanning failure, it is an ownership failure. The core problem is that many application security programmes still treat authorization as a secondary test after authentication succeeds. In reality, the security decision depends on whether the caller owns the object, the tenant, or the action. That makes ownership context a governance control, not a debugging detail. Practitioners should treat object ownership as part of access policy.
A question worth separating out:
Q: How do organisations reduce the impact of IDOR findings in production?
A: They should enforce object-level authorization in the application layer, log denied access attempts with tenant context, and remove assumptions that session login alone is enough. In parallel, they need fast triage so suspicious response differences are investigated before related endpoints are abused. The goal is to prove isolation, not just detect leaks.
👉 Read our full editorial: IDOR vulnerabilities evade DAST because ownership context is missing
