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.
Report a privacy-bounded access outcome
Section titled “Report a privacy-bounded access outcome”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:
deniedandallowedfor ordinary observed results;unexpected_allowedwhen your policy layer explicitly says the success was unexpected;policy_mismatchwhen the observed result disagrees with a trusted authorization decision; anddecoy_accessfor 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.
Findings
Section titled “Findings”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 and privacy
Section titled “MCP and privacy”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.