During a synchronous RFC, the called system can invoke a function back in the client system under the initiating user’s context.
Connection direction is not the whole story
Callback uses the existing connection and destination BACK. It does not perform a new user logon, but remains subject to S_RFC and any functional checks in the client.
Risk increases when a highly privileged account, such as a batch user, calls a less trusted system. This callback mechanism applies to synchronous RFC; aRFC, tRFC, qRFC and bgRFC do not support it.
Allowlist function pairs
Each allowlist entry pairs the function called in the target system with the function permitted to be called back. The configuration applies to ABAP and TCP/IP destinations. DYNAMIC_DEST_CALLBACK_WHITELIST covers dynamic destinations.
Supported releases can analyze logs and generate lists in SM59. Locally calling RFC_CALLBACK_REJECTED before the outbound call rejects callbacks programmatically and takes precedence over an allowlist.
Parameter values and rollout phases
| Value | Behavior |
|---|---|
0 | Disables callback logging and active allowlist checks; unsuitable for business-critical systems. |
1 | Initial logging; active allowlists can still enforce restrictions. |
2 | Simulates inactive allowlists and reports missing entries. |
3 | Enforces active and inactive lists after all relevant destinations are prepared. |
The parameter is rfc/callback_security_method. Include DUI for executed callbacks, DUJ for rejected callbacks and DUK for simulation violations in SAL. Review and complete the lists before enabling enforcement.
Review checklist
- Identify synchronous RFC calls to lower-classification systems.
- Enable SAL filters for DUI, DUJ and DUK.
- Prepare allowlists, review simulation results and activate restrictions.
- Do not set value 3 before preparing every affected destination.