ALV Reports Part 10: Authorization and Sensitive Data in ALV Reports

📌 KEY POINTS
✅ An ALV shows everything in its output table — authorization must be checked before rows go into it.
✅ Check at two levels: transaction/report start (S_TCODE / custom object) and per organizational unit (company code, sales org, plant).
✅ Hide or mask sensitive columns (salary, bank data, personal data) for users without a display authorization.
⚠️ Hiding a column with no_out is NOT security — users can show it via the layout. Remove or mask the data itself.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–9 built functional ALVs. A report that shows payroll, vendor bank data or customer personal data must also be safe — this is a common audit finding.

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHERE CHECKS BELONG

• Transaction start: S_TCODE is checked automatically for the transaction; reports run via SA38 need their own check (authorization group in report attributes or AUTHORITY-CHECK in INITIALIZATION / AT SELECTION-SCREEN).
• Selection screen: check the entered organizational values (e.g. all company codes in s_bukrs) at AT SELECTION-SCREEN.
• Rows: after selecting data, remove rows the user may not see (check each distinct org value once, not each row).

━━━━━━━━━━━━━━━━━━━━
▶ 2. AUTHORITY-CHECK
AUTHORITY-CHECK OBJECT 'F_BKPF_BUK' ID 'BUKRS' FIELD lv_bukrs ID 'ACTVT' FIELD '03'.
sy-subrc = 0 means allowed. Use standard objects where they exist; create custom objects (SU21) for custom data. Use SU53 / ST01 (STAUTHTRACE) to analyse failures.

━━━━━━━━━━━━━━━━━━━━
▶ 3. SENSITIVE COLUMNS

• If the user lacks the "sensitive display" authorization: clear or mask the values (e.g. IBAN → DE893000) in the output table and mark the column tech = 'X'.
• Never rely on no_out: the layout dialog can show it again.
• Consider a separate output structure without sensitive fields.

━━━━━━━━━━━━━━━━━━━━
▶ 4. EXPORT AND LAYOUTS

• Export to Excel/local file bypasses screen masking only if data is in the table — masking in data solves both.
• Exclude functions (e.g. &XXL, &PC export) for reports with very sensitive data: it_excluding (REUSE_ALV) or it_toolbar_excluding (CL_GUI_ALV_GRID).
• Global layouts (i_save 'X'/'A') should be allowed only for key users if layouts expose extra columns.

━━━━━━━━━━━━━━━━━━━━
▶ 5. DRILL-DOWN
Check authorization before CALL TRANSACTION (Part 6) — the called transaction may check it too, but a clear message is better than an error screen.

━━━━━━━━━━━━━━━━━━━━
▶ 6. PERFORMANCE
Check each distinct company code once (collect distinct values, check, then delete rows) rather than AUTHORITY-CHECK in a loop over 100,000 rows.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Run the code example with a user who has access to only one company code.
2. Observe removed rows and the masked bank account column.
3. Trace the checks with STAUTHTRACE.

✅ CHECKPOINT: your ALV shows only what the user is allowed to see, even after layout changes or export.

An internal audit found that a custom vendor ALV showed bank account numbers to all AP clerks. The developer had set no_out on the BANKN column, but any user could add it back through "Change layout" and export it.
The fix masked the bank account in the output table unless the user had a new custom authorization object for bank data, removed local export for others, and added a company-code check at the selection screen. The audit finding was closed after a test with restricted users and STAUTHTRACE evidence.

• Hiding sensitive columns with no_out and calling it secure.
• No company-code/org-level checks in custom reports.
• AUTHORITY-CHECK inside a loop for every row.
• Forgetting that export and layouts expose all columns in the table.
• Not testing with a restricted user.

• Check org-level authorization at selection and filter data before display.
• Mask or omit sensitive data in the table itself.
• Use standard authorization objects; create custom ones for custom data.
• Restrict export functions where required.
• Test with restricted users and document checks for audits.

Questions: "How do you secure an ALV report?", "Is no_out enough to hide salary data?", "How do you check authorizations efficiently?"
Strong answer: AUTHORITY-CHECK at selection (org levels like BUKRS/VKORG/WERKS) and remove unauthorized rows by distinct values; sensitive fields masked or removed from the output table (no_out is not security — layouts/export show it); exclude export functions if needed; check before drill-down; analyse with SU53/STAUTHTRACE; test with restricted users.