Well, here are my top priority security recommendations for developing secure ABAP applications:
New database tables
Assign a table authorization group which enables the authorization check for the authorization object S_TABU_DIS within transactions like SE16 or SM30.
You can use the report RDDPRCHK (or RDDTDDAT_BCE) to analyze the settings.
Use transaction SM30 for view V_BRG_54 to maintain authorization groups respective view V_DDAT_54 to maintain authorization group assignments.
Alternate solution: If you use the authorization object S_TABU_NAM instead of S_TABU_DIS, than you can omit table authorization groups.
Set the maintenance flag which controls SE16 and SM30 correctly
Activate table logging for customizing table or create a change document object for master data. You can use the report RDDPRCHK (or RDDTDDAT_BCE) to analyze the settings. Check the settings of profile parameter rec/client and the tp parameter RECCLIENT, too.
Create specialized SM30 maintenance views instead of offering maintenance using SE16 and add additional authorization checks if required.
New transactions
Assign authorization object with appropriate field values in the definition of the transaction using transaction SE93.
Enter authorization proposals using transaction SU24.
If the transaction is a report transaction and you have decided that the authorization check for the transaction is important: Check the authorization again using function AUTHORITY_CHECK_TCODE within the code of the report.
New BAPI / RFC Function
Ensure that application specific authorization checks are executed.
Put critical and non-critical RFC functions into separate function groups. (Well, you might assume that this is not important anymore because you can provide authorizations for S_RFC for individual functions, too, but I guess that many roles still contain authorizations for function groups.)
New Web UI
Critical ABAP statements
Have a close look at critical ABAP statements. You can use the Code Inspector, transaction SCI, to search for such statements in custom code.
INSERT REPORT / GENERATE SUBROUTINE POOL
These statements allow to create arbitrary code. Avoid anything which would enable users to inject ABAP code.
CALL TRANSACTION
The statement CALL TRANSACTION does not check the authorization of the current user to execute the called transaction automatically. To do this, either the calling (preferred) or the called program must call function module AUTHORITY_CHECK_TCODE. You can replace CALL TRANSACTION by calling function ABAP4_CALL_TRANSACTION, too. This function executes all neccessary authorization checks.
CALL 'SYSTEM'
This statement sends operation system commands to the application server which are then executed by the powerfull user
Generic functionality
Avoid developing generic functionality which enables the user to choose any target table, file, report or transaction. Have a close look to these statements:
Other blogs:
Code Scanning for vulnerabilities
Knowing about the rules for developing secure software is one part of the game. The other is to search for security vulnerabilities in existing code and to prevent to introduce security vulnerabilities while developing new code.
For several years you could have used the
Code Profiler from partner
Virtual Forge. SAP consulting offers a service to scan your ABAP code using that tool as well (seen note
1531056).
Since 2013, SAP offers a security code scanner as part of the develpment workbench. The add-on tool is called
SAP NetWeaver Application Server, add-on for code vulnerability analysis
(short name: code vulnerability analyzer)
Here are some links for further reading:
Kind regards
Frank Buchholz
Active Globas Support - Security Services