Skip to content

Authorization attack correlation

Object-level authorization attacks are sequences. One request for an order or document is ordinary; one identity walking many objects and then reaching an explicit policy mismatch or decoy object is materially different. WebDecoy correlates that sequence from a small assertion produced inside your trusted authorization boundary.

Enumeration alone is informational. It does not prove BOLA, IDOR, or unauthorized access, does not change a threat score, and does not create a blocking rule.

Send object_access at the top level of an authenticated, property-scoped SDK request:

{
"request_metadata": {
"method": "GET",
"path": "/api/orders/123",
"ip": "203.0.113.10"
},
"object_access": {
"schema_version": 1,
"route_template": "/api/orders/:id",
"resource_id": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
"subject_id": "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
"authorization_outcome": "denied",
"status_class": "4xx",
"traversal": "sequential",
"client_class": "standard",
"sample_rate_basis_points": 10000
}
}

Compute resource_id and optional authenticated subject_id as lowercase HMAC-SHA-256 digests under a secret key dedicated to that WebDecoy property. Never send the source object ID, account ID, HMAC key, authorization header, request body, or response body. Property-specific keys prevent either digest becoming a cross-site join key.

The trusted integration classifies traversal as sequential, sparse, or unknown; this is not inferred from the digest. It also classifies the caller as standard, pagination, or approved_bulk. Pagination and approved bulk clients are retained as coverage assertions but excluded from these correlation rules. Derive these fields from server policy—not visitor parameters or headers.

Allowed authorization outcomes are:

  • denied and allowed for ordinary observed results;
  • unexpected_allowed when your policy layer explicitly says the success was unexpected;
  • policy_mismatch when the observed result disagrees with a trusted authorization decision; and
  • decoy_access for an object that no legitimate principal should request.

An ordinary allowed response never becomes boundary evidence merely because failures preceded it. The contract rejects unknown fields, raw identifier fields, credentials, headers, and bodies. Requests without a trusted object_access have unknown coverage.

WebDecoy evaluates one route template and one property-scoped authenticated subject or strong actor over 15 minutes:

Finding Minimum sequence Meaning
Sequential enumeration At least 10 distinct resource digests classified sequential Informational breadth, not proof of unauthorized access
Sparse enumeration At least 10 distinct resource digests classified sparse Informational sampling, not proof of unauthorized access
Authorization progression Either enumeration pattern followed by unexpected_allowed, policy_mismatch, or decoy_access Boundary risk; only mismatch and decoy outcomes are high-signal

Repeated access to one resource does not meet the breadth threshold. A coarse shared-network actor is insufficient unless the trusted server supplies a subject digest. Sampled reporters preserve their minimum sampling rate as a coverage limitation, so a partial window is not presented as complete.

MCP correlation results expose the rule, route template, traversal class, boundary outcome when present, status class, aggregate resource/denied/allowed counts, and whether coverage is complete. They never expose resource digests, subject digests, or per-event authorization evidence.

Resolve a high-signal result against your own authorization and audit records. boundary_risk is not confirmation; high_signal means the trusted integration reported a concrete mismatch or decoy result, not that WebDecoy independently proved data exposure.