Using "CALL TRANSACTION" statements without an authority check is security sensitive. Its access should be restricted to specific users.
This rule raises when a CALL TRANSACTION has no explicit authorization check, i.e. when:
- the
CALL TRANSACTION statement is not followed by WITH AUTHORITY-CHECK.
- the
CALL TRANSACTION statement is not following an AUTHORITY-CHECK statement.
- the
CALL TRANSACTION statement is not following a call to the AUTHORITY_CHECK_TCODE function.
Ask Yourself Whether
- the
CALL TRANSACTION statement is restricted to the right users.
There is a risk if you answered no to this question.
Recommended Secure Coding Practices
Check current user’s authorization before every CALL TRANSACTION statement. Since ABAP 7.4 this should be done by appending WITH
AUTHORITY-CHECK to CALL TRANSACTION statements. In earlier versions the AUTHORITY-CHECK statement or a call to the
AUTHORITY_CHECK_TCODE function can be used.
Note that since ABAP 7.4 any CALL TRANSACTION statement not followed by WITH AUTHORITY-CHECK or WITHOUT
AUTHORITY-CHECK is obsolete.
Sensitive Code Example
CALL TRANSACTION 'MY_DIALOG'. " Sensitive as there is no apparent authorization check. It is also obsolete since ABAP 7.4.
Compliant Solution
AUTHORITY-CHECK OBJECT 'S_DIAGID'
ID 'ACTVT' FIELD '03'.
IF sy-subrc <> 0.
" show an error message...
ENDIF.
CALL TRANSACTION 'MY_DIALOG'. " Ok but obsolete since ABAP 7.4.
or
CALL FUNCTION 'AUTHORITY_CHECK_TCODE'
exporting
tcode = up_fdta
exceptions
ok = 0
others = 4.
IF sy-subrc <> 0.
" show an error message...
ENDIF.
CALL TRANSACTION up_fdta USING up_bdc mode 'E'. " Ok but obsolete since ABAP 7.4.
or
CALL TRANSACTION 'MY_DIALOG' WITH AUTHORITY-CHECK. " Recommended way since ABAP 7.4.
Exceptions
No issue will be raised when CALL TRANSACTION is followed by WITHOUT AUTHORITY-CHECK as it explicitly says that the
TRANSACTION does not require an authorization check.
See
