Skip to main content

How IDOR Vulnerabilities Lead to Unauthorized Access (And How to Prevent It)

Attackers don't always break through the front door. Sometimes they just change a number in a URL. Insecure Direct Object Reference (IDOR) vulnerabilities let them access records, files, or actions that belong to someone else by manipulating an identifier the application exposed and failed to verify.

In Guidewire implementations, custom REST API integrations, PCF screens, and Gosu extensions can all introduce IDOR risks (referred to as Broken Object Level Authorization [BOLA] when the vulnerable object is an API resource) if object-level authorization isn't enforced on every request.

What Is IDOR?​

IDOR is an access control vulnerability that occurs when an application uses a user-controlled identifier (like a claim number, policy ID, or document reference) to retrieve or modify an object, without first checking whether the requesting user has permission to access that specific object.

Authentication tells the application who you are. Authorization determines whether that user should access a specific record.

The identifier doesn't have to be a sequential integer. IDOR vulnerabilities can involve:

  • Sequential numeric IDs in URLs or query parameters (for example, claimId=10452)
  • GUIDs or UUIDs that are assumed to be unguessable but aren't validated
  • File names or document paths passed in API requests
  • Internal references embedded in API response payloads that clients reuse in subsequent calls

Common IDOR Attack Scenarios​

IDOR vulnerabilities are exploited when a user manipulates a reference to an object they don't own. The application retrieves or modifies the object without verifying the requester's authorization.

NameDiscriptionExample
Unauthorized data accessA user reads another user's records by changing an identifier in a request.A policyholder modifies policyId=8821 to policyId=8822 in a ClaimCenter API call and retrieves another claimant's personal injury details.
Unauthorized data modificationA user modifies another user's records by supplying a different object reference.An adjuster changes documentId=441 in a PUT request and overwrites a document attached to a claim they're not assigned to.
Privilege escalation via referenceAn unprivileged user accesses an administrative resource by guessing or enumerating its identifier.A standard user calls /api/v1/admin/users/55 directly, bypassing the user interface check that hides the link.
File and document exposurePredictable file names or paths in download URLs expose documents to unauthorized users.An uploaded claim attachment is served at /documents/claims/2024/claimant_ssn_scan.pdf. Any authenticated user who guesses the path downloads it.
Mass enumerationAn attacker iterates through a range of identifiers to harvest data at scale.An automated script cycles through claimId values 10000–20000, collecting claimant PII from each response.

Security and Business Impacts​

IDOR vulnerabilities are consistently ranked among the most impactful access control weaknesses because they're often easy to exploit and hard to detect in logs. A successful exploit doesn't trigger authentication failures. The request looks like a legitimate, authorized call.

  1. Data Exposure: Unauthorized access to policyholder records, claim details, payment information, or personal data can lead to identity theft and financial harm.
  2. Regulatory Non-Compliance: Exposing personal data through IDOR may violate GDPR, CCPA, or other applicable privacy regulations, resulting in fines and mandatory disclosure obligations.
  3. Unauthorized Modification: Attackers can alter records they don't own, changing coverage details, approving claims, or modifying financial transactions, without leaving obvious authentication trails.
  4. Loss of Trust: Policyholders and partners who discover their data was accessed by another party lose confidence in the platform and the insurer operating it.
  5. Audit and Forensic Complexity: Because IDOR exploits use valid sessions and valid endpoints, distinguishing malicious access from legitimate access during an investigation is difficult and time-consuming.

How to Prevent IDOR Vulnerabilities​

Preventing IDOR requires consistent authorization and access validation wherever objects are retrieved or modified. The following strategies work together to reduce exposure and strengthen access controls.

1. Enforce Object-level Authorization on Every Request​

The core fix for IDOR is straightforward. Before returning or modifying any object, verify that the authenticated user is authorized to access that specific object, not just that they're authenticated. This check must happen server-side on every request, regardless of what the user interface shows or hides.


// Vulnerable: retrieves a claim using only the ID from the request
var claim = gw.api.database.Query.make(Claim).compare("ClaimNumber", Relop.Equals, claimNumber).select().first()
return claim

// Safer: verifies the claim belongs to the current user's context before returning it
var claim = gw.api.database.Query.make(Claim)
  .compare("ClaimNumber", Relop.Equals, claimNumber)
  .compare("AssignedUser", Relop.Equals, CurrentUser)
  .select().first()
if (claim == null) {
  throw new PermissionException("Access denied.")
}
return claim

2. Use Indirect Object References Where Possible​

Instead of exposing raw database identifiers in URLs or API responses, map them to session-scoped or context-scoped references that have no meaning outside the current user's session. If an identifier leaks, it can't be reused by another user.


// Vulnerable: exposes the internal database ID directly
response.write("{ \"claimId\": " + claim.ID + " }")

// Safer: returns a session-scoped reference that the server resolves back
// to the real object on the next request, after re-validating ownership
var sessionRef = SessionReferenceMap.register(CurrentUser, claim.ID)
response.write("{ \"claimRef\": \"" + sessionRef + "\" }")

3. Apply Guidewire Role-based Access Control at Every Layer​

Guidewire's role configuration supports authorization checks across PCF screens, Gosu business logic, and REST API endpoints. Don't enforce authorization in only one layer and assume the others are covered. An attacker calling a REST API directly bypasses any PCF-level visibility checks.

Apply consistent role checks in:

  • PCF screen visibility and editability conditions
  • Gosu service and rule logic that acts on objects
  • Custom REST API endpoints built using Guidewire's REST framework

// Check role permission before processing a sensitive operation
if (!perm.Claim.view(claim)) {
    throw new PermissionException("You don't have permission to view this claim.")
}

4. Don't Expose Predictable Identifiers in File Download URLs​

If documents or attachments are served via URLs that include predictable paths or file names, any authenticated user who guesses the URL can download them. Serve files through a controller that validates the requester's authorization before streaming the content, rather than relying on the URL itself to act as an access control.

5. Log and Monitor Object-level Access​

Because IDOR exploits use valid sessions, you won't catch them by monitoring authentication failures. Log access to sensitive objects, particularly claims, policy records, payment details, and documents, and monitor for patterns that suggest enumeration: a single session accessing many different object IDs in a short window.

Guidewire Implementation Considerations​

Guidewire's base configuration includes role-based access control infrastructure. The platform enforces permissions tied to Gosu business rules and PCF screen configurations out of the box. However, when you build custom REST API integrations, Gosu extensions, or external-facing Digital Portal features, you're responsible for extending those authorization checks to cover your custom object access paths.

Pay particular attention to:

  • Custom REST Endpoints: Any endpoint you build that accepts an object identifier as a parameter must validate that the current user has permission to access that specific object, not just that they're authenticated.
  • Document Management System (DMS) Integrations: Custom IDocumentContentSource implementations that resolve document references must verify ownership before returning content.
  • Claim and Policy Search Results: If you expose search functionality that returns references to objects, validate on retrieval, not just on initial search, that the user is still authorized to access each returned object.

Your Implementation Responsibilities​

Guidewire provides role-based access control infrastructure and enforces it within the platform's own features. You're responsible for:

  • Extending authorization checks to all custom API endpoints, Gosu logic, and integrations that access objects by reference
  • Avoiding the use of raw database identifiers in externally exposed URLs or API payloads where possible
  • Monitoring access logs for enumeration patterns and taking action on anomalies
  • Including IDOR as an explicit test case in security testing for any custom implementation that exposes object references

Additional Resources​

To further strengthen your understanding and implementation, these resources provide additional guidance on secure coding practices.

OWASP:

Guidewire:

Legal and Support Information
Copyright © 2001-2026 Guidewire Software, Inc.