APP.4.6 SAP ABAP Programming

It MUST be ensured that only authorised users can start self-programmed evaluations (reports). Therefore, each report MUST perform explicit authorisation checks appropriate to the context at hand.

Each authorisation check in code MUST be evaluated by querying the return value SY-SUBRC.

If developers use the CALL TRANSACTION command, a start authorisation check MUST always be performed before the command is executed.

Each authorisation check MUST be carried out using the AUTHORITY CHECK command provided for this purpose. Proprietary authorisation checks (e.g. based on user names) MUST NOT be used.

A policy SHOULD be drawn up for the development of ABAP programs. In addition to naming conventions, the policy SHOULD contain specifications for ABAP elements that may or may not be used. The requirements from this module SHOULD be included in the policy. The policy SHOULD be binding for Developers.

During an authorisation check in ABAP code (AUTHORITY-CHECK <OBJECT>), it SHOULD be ensured that all fields are checked for the relevant authorisation object. If individual fields are not actually required, they SHOULD be marked as DUMMY. The reason for the exception SHOULD also be documented in the field.

The function codes and screen elements of ABAP Dynpro applications SHOULD be consistent. If a screen element has been deactivated, an application SHOULD NOT react to the events of this element without adequate authorisation checks. If certain entries in a Dynpro menu are hidden or individual buttons are disabled, the corresponding function codes SHOULD also not be executed.

If access to files on an SAP server depends on user input, this input SHOULD be validated before access is granted.

It SHOULD be ensured that all remote-enabled function modules in program code explicitly check whether the initiator is authorised to execute the corresponding business logic.

Each call of a permitted operating system command SHOULD be preceded by a corresponding authorisation check (authorisation object S_LOG_COM). User input SHOULD NOT be part of a command. For this reason, operating system calls SHOULD only be executed using standard SAP function modules intended for this purpose.

The ABAP commands INSERT REPORT and GENERATE SUBROUTINE POOL SHOULD NOT be used.

Transactions, programs, function modules, and methods SHOULD NOT be generically executable. If there are important reasons for a generic execution, where and why this is happening SHOULD be documented in detail. In addition, a whitelist SHOULD be defined that contains all the permitted modules. Before a module is called, the user's input SHOULD be compared against the whitelist.

Table contents SHOULD NOT be read generically. If there are important reasons for doing this, where and why this is happening SHOULD be documented in detail. It SHOULD also be ensured that the dynamic table name is restricted to a controllable list of values.

The ABAP Database Connectivity (ADBC) interface SHOULD NOT be used. User input SHOULD NOT be part of ADBC commands.

A sufficiently secure authorisation check SHOULD be performed before business-critical data is displayed, transmitted, or exported. Planned (intended) export options SHOULD be documented.

ABAP programs SHOULD NOT be programmed in a system-dependent manner—that is, so that they can only be executed on a particular SAP system. Should this be absolutely necessary, however, it SHOULD be documented in detail. In addition, the code SHOULD then be checked manually.

ABAP programs SHOULD NOT be programmed in a client-dependent manner—that is, so that they can only be executed by a particular client. Should this be absolutely necessary, however, it SHOULD be documented in detail. In addition, further security measures SHOULD then be taken, such as a manual code review or quality assurance on the corresponding client.

Dynamic Open SQL SHOULD NOT be used. If database access with dynamic SQL conditions is necessary, user input SHOULD NOT be transferred in the respective query. If this is nevertheless the case, the user input MUST be checked (output encoding).

Custom-developed HTML in Business Server Page (BSP) applications or HTTP handlers SHOULD be avoided whenever possible.

Automatic client separation SHOULD NOT be bypassed. Data from other clients SHOULD NOT be accessed using EXEC SQL or the Open SQL option CLIENT SPECIFIED.

The source code of an ABAP program created in-house SHOULD always be readable. Techniques that prevent this (obfuscation) SHOULD NOT be used.

An ABAP code analysis tool SHOULD be used to automatically check ABAP code for security-relevant programming errors, functional and technical errors, and quality vulnerabilities.