When companies migrate from SAP ECC to S/4HANA, they're not just upgrading their system-they're often carrying decades of security problems with them. This research looks at the most common security vulnerabilities in custom ABAP code and the mistakes organizations make during S/4HANA migrations.
According to security experts at RedRays, over 80% of SAP systems they've tested contain critical security flaws or misconfigurations that could lead to business compromise. As SAP systems move to web-based interfaces like Fiori, old vulnerabilities become much more dangerous because they're now accessible from the internet.
Why ABAP Security Matters
ABAP (Advanced Business Application Programming) is the language used to customize SAP systems for specific business needs. While this flexibility is powerful, it also creates security risks. Many organizations run custom code written decades ago-before secure coding practices were standard in SAP development.
When companies migrate to S/4HANA using a "lift-and-shift" approach, they bring all these old security holes into a new, web-oriented environment. What was once only accessible from inside the company network can now be exploited via internet protocols.
Common Risk Areas
Top 10 Vulnerabilities in Custom ABAP Code
Based on analysis from RedRays and SAP Security Notes, here are the ten most critical vulnerability categories found in custom developments.
1. Missing Authorization Checks
This is the most common mistake in ABAP code-developers forget to add AUTHORITY-CHECK statements before critical data operations. Many developers wrongly assume that if a user has permission to run a transaction (T-code), they automatically have rights to view or modify all data within that transaction.
The problem is that SAP doesn't enforce authorization checks at the database level for custom code. As a result, a user with access to a simple materials report might see data for all plants and storage locations, even those they shouldn't have access to according to organizational structure.
2. SQL Injection in Open SQL and Native SQL
While Open SQL provides some protection, using dynamic conditions in WHERE clauses or executing Native SQL via ADBC interface opens the door to SQL injection attacks. Attackers can manipulate input parameters to change query logic, bypass filters, or access system tables like USR02 (password storage).
A critical example is CVE-2025-0063, discovered in RFC modules for Informix databases. It allowed users with minimal privileges to inject malicious SQL code into host variables, leading to complete compromise of database integrity and availability.
CL_ABAP_DYN_PRG class for strict validation and escaping of all dynamic query elements.
3. ABAP Code Injection
This vulnerability is rated critical (CVSS 9.9) and allows attackers to inject arbitrary ABAP statements directly into the system execution environment. Using constructs like INSERT REPORT or GENERATE SUBROUTINE POOL without proper authorization checks on S_DEVELOP object turns the system into an open book for attackers.
CVE-2025-42957 in the /SLOAE/DEPLOY module demonstrated how insufficient parameter validation in RFC functions allows low-privileged users to create new programs, execute OS-level commands, and create users with SAP_ALL privileges.
4. Cross-Site Scripting (XSS) in Web Dynpro and Fiori
With the shift to web-based interfaces like SAP Fiori and Web Dynpro ABAP, XSS has become one of the three most frequently patched vulnerabilities. The problem occurs when user-entered data is displayed in browsers without proper encoding.
Attackers can use XSS for phishing within the corporate network, intercepting authentication tokens, or performing unauthorized actions as an administrator.
5. Insecure Remote Function Calls (RFC)
RFCs are the backbone of communication between systems in SAP landscapes, but they're often configured insecurely. Common mistakes include no checks on S_RFC object, using trusted connections without restrictions, and exposing critical functions to external networks.
Attackers often use RFC for lateral movement. Compromising a secondary system connected via RFC to a productive S/4HANA environment allows attackers to use the trusted communication channel to execute commands in the business core.
6. Directory Traversal
Using OPEN DATASET with user-controlled parameters can lead to unauthorized reading or writing of files on the application server. If the file path isn't normalized, attackers can use ../ sequences to escape the allowed directory and access sensitive OS files or system logs.
FILE) and validate paths through standard SAP function modules like FILE_GET_NAME.
7. Insecure Deserialization
Deserialization vulnerabilities like CVE-2025-30012 allow attackers to manipulate data objects passed between Java and ABAP stacks. If the system trusts incoming byte streams without validating their structure, attackers can inject "gadgets"-fragments of existing code that execute malicious actions during deserialization, up to remote code execution (RCE).
In ABAP development, this is relevant when using classes like CL_ABAP_SERIALIZER or passing complex data structures through binary interfaces.
8. Hard-coded Secrets
Storing passwords, API keys, or tokens directly in program code is a classic mistake that makes the system vulnerable to anyone with code viewing access (transactions SE38, SE80). These secrets also end up in version control systems and transport requests, becoming available at all landscape stages (DEV, QAS, PRD).
SSFC_STRING_ENCRYPT for handling sensitive information.
9. Missing Audit Trails
Many custom programs modify critical business data (such as prices or partner information) without leaving traces in system logs. In case of a security incident or internal fraud, the absence of an audit trail makes investigation and identifying culprits impossible.
SM20) and use Change Documents mechanisms for all significant operations.
10. Structural Defects and Performance Issues (ABAP Crimes)
While not always a direct vulnerability, poor code structure (lack of modularity, nested loops with database queries) can lead to Denial of Service (DoS). In S/4HANA environments designed for high-speed in-memory processing, unoptimized legacy code can paralyze the HANA database by consuming all available resources.
Critical S/4HANA Migration Mistakes
Migrating to S/4HANA isn't just a technical upgrade-it's a complete ERP system transformation. During this period, security is often sacrificed for project timelines, creating long-term risks.
Mistake 1: Neglecting Role and Authorization Redesign
The most common mistake is trying to transfer existing roles from ECC to S/4HANA "as is." In S/4HANA, many transactions are obsolete or have been replaced (for example, MB1A, MB1B merged into MIGO). Additionally, implementing Fiori requires completely new authorizations for OData services and UI5 applications.
Failure to adapt the Segregation of Duties (SoD) matrix to the new Business Partner architecture (which combines vendors and customers) can lead to critical authorization conflicts enabling fraudulent activities.
Mistake 2: No "Clean Core" Strategy
Many companies continue developing complex extensions directly inside the system core, ignoring SAP recommendations to use SAP Business Technology Platform (BTP) for "Side-by-Side" extensions.
This leads to technical debt accumulation:
- Complications in future system updates
- Core instability due to custom code incompatibility with simplified HANA data models (e.g.,
ACDOCAtable) - Increased attack surface from millions of lines of unverified code inside ERP
Mistake 3: Data Integrity and Confidentiality Issues During Migration
Data migration often involves format errors, record duplication, and loss of historical links. From a security perspective, a critical mistake is transferring unanonymized personal data to test and sandbox migration environments-a direct GDPR violation.
Mistake 4: Insufficient Attention to OData and Fiori Security
Transitioning to web interfaces requires implementing new defense layers such as Web Application Firewall (WAF) and SAP Web Dispatcher. Many organizations make the mistake of opening access to OData services without proper backend authorization checks, relying only on visual restrictions in the Fiori application. Attackers can call services directly through browser developer tools and access data hidden in the UI.
Protection Strategy and Automation Role
To minimize risks, organizations should move from periodic audits to continuous code security monitoring.
Using ABAP Test Cockpit (ATC) and RedRays Solutions
Standard SAP tools like ATC and SAP Code Vulnerability Analyzer (CVA) provide basic security checks but often require additional licenses and complex configuration. The RedRays ABAP Security Scanner platform complements these tools by offering:
- Deep Data Flow Analysis (Taint Analysis): Tracks data path from user input to dangerous code operators
- Reduced False Positives: Thanks to SAP-context awareness, saving developer time
- CI/CD Integration: Allows code checking during writing, implementing a "Shift Left" approach
Secure Migration Recommendations
- Conduct Full Custom Code Audit before starting migration using SAP Readiness Check and specialized scanners like RedRays ABAP Scanner
- Implement "Clean Core" Principle: Remove unused code (Soft Cleaning technology) and move innovations to BTP
- Automate Authorization Testing: Use tools for trace analysis and automatic role creation based on actual function usage
- Ensure Infrastructure Security: Configure network segmentation, update OS and HANA DB patches, activate SAP Security Audit Log
Conclusion
SAP S/4HANA security is an ongoing process requiring integration of efforts from developers, basis specialists, and security auditors. Vulnerabilities in custom ABAP code remain the most likely attack vector on business-critical systems, and migration mistakes can lay the foundation for future incidents.
The transition to S/4HANA provides a unique opportunity to clean the system of accumulated risks and build a modern, threat-resistant architecture. Using advanced automation tools like RedRays ABAP Scanner, combined with a strategic approach to migration, allows organizations to protect their most valuable assets and ensure business continuity in an era of digital instability.
Protect Your SAP Systems from ABAP Code Vulnerabilities
Don't let hidden security flaws compromise your business. RedRays ABAP Security Scanner provides deep code analysis, continuous monitoring, and automated detection of all 10 vulnerability types discussed in this article.
Learn More About RedRays ABAP Scanner →
