Authorization and Sensitive Data in ALV Reports

Explanation

ALV reports often display financial, HR, customer, vendor, pricing or operational data. Developers must ensure users see only what they are authorized to view. Authorization checks should happen before data selection or before sensitive fields/actions are displayed. Hiding columns on the frontend is not enough if sensitive data was already selected and stored. Drill-down actions should also respect authorization. Custom ALV reports do not automatically inherit all standard transaction checks.

Code example

* Purpose:* Check user authorization before selecting or displaying sensitive company-code data.* This prevents custom ALV reports from exposing unauthorized financial information. AUTHORITY-CHECK OBJECT 'F_BKPF_BUK'  ID 'BUKRS' FIELD p_bukrs  ID 'ACTVT' FIELD '03'. IF sy-subrc <> 0.  * Stop report before selecting sensitive data  MESSAGE 'You are not authorized for this company code' TYPE 'E'.ENDIF. * Only select data after authorization is confirmedSELECT bukrs, belnr, gjahr, budat  FROM bkpf  INTO TABLE @DATA(lt_bkpf)  WHERE bukrs = @p_bukrs.

Real project scenario

A customer aging report shows credit exposure. The developer adds company-code authorization checks and hides credit-related fields for unauthorized users.

Common mistakes

- Selecting sensitive data before authorization check. - Only hiding columns after data is already selected. - Not checking authorization before drill-down. - Assuming custom reports inherit standard transaction security automatically.

Best practices

- Check authorization before selecting sensitive data. - Do not expose unauthorized fields. - Validate authorization before update or drill-down. - Avoid logging sensitive data unnecessarily.

Interview angle

A mature answer should mention authorization checks before selection, sensitive fields and secure drill-down actions.