● Patterncross_domain_logicAuthorization bindingPublic-safe
Proof / Cross-domain logic abuse
CS.03
Cross-domain logic abuse.
A system validates an actor, message or outer operation, but fails to bind the final asset, tenant, token, repository, domain, recipient or controller back to that same authorization context. Authorization for object A is rebound to object B.
The shape
- A valid authorization exists for object A in domain A.
- Attacker-controlled forwarding, hook, callback, request or manifest data introduces object B or domain B.
- The system validates the outer authorization but trusts the inner object.
- The operation consumes or mutates object B without authorization for that object/domain pair.
Representative findings (redacted)
| Redacted ID | Pattern | Impact class |
|---|---|---|
| BB-XD-001 | Withdrawal authorization can forward a different supported asset | Unauthorized reserve movement |
| BB-XD-002 | Forwarding calldata can rebind remote domain | Cross-domain value movement |
| BB-XD-003 | Address-book or manifest isolation fails across wallet boundary | Cross-account trust break |
| BB-XD-004 | Remote executable duplicate write crosses intended object binding | Repeated or misplaced state write |
| BB-XD-005 | Callback ticket or token can bridge login state across domains | Session confusion |
High-signal checks
- Is the target object supplied by the client when it could be derived server-side?
- Is ownership checked on the object that actually changes state?
- Can hook data or forwarding calldata select a different asset, amount, recipient, repository or domain than the validated outer request?
Related: Runtime authorization replay · Validation boundary bypass