How to Secure SAP Fiori Launchpad from Web Attacks

Understanding the SAP Fiori Attack Surface

SAP Fiori Launchpad is not a single application but a gateway that orchestrates access to hundreds of SAP Fiori apps, each exposing OData services, CDS views, and backend RFC calls. This architectural complexity creates multiple attack vectors that traditional web application firewalls (WAFs) often miss.

OData and RFC Interface Exposure

Every Fiori app communicates with the SAP backend through OData services. These services, if not properly secured, allow attackers to enumerate business data, inject malicious OData queries, or bypass authorization checks. The /sap/opu/odata/ endpoint, commonly exposed for Fiori, is a frequent target for reconnaissance and data extraction attacks. Compounding this risk, many SAP landscapes still expose RFC destinations directly without enforcing Transport Layer Security (TLS), enabling man-in-the-middle attacks on Fiori-to-backend communication.

XSS, URI Manipulation, and CSRF Threats

Cross-site scripting (XSS) remains the most prevalent web vulnerability in custom Fiori apps. When development teams build custom UI5 applications without proper input sanitization, attackers can inject malicious scripts that execute in the context of the user's Launchpad session. URI manipulation attacks exploit predictable URL patterns in Fiori Launchpad to directly access apps outside the user's assigned role. Cross-site request forgery (CSRF) tokens, while enforced by default in modern S/4HANA systems, are often disabled in legacy or custom-integration scenarios, opening a path for unauthorized transaction execution.

SAP Fiori Security Baseline Controls

Before layering external monitoring tools, organizations must establish a hardened foundation. These baseline controls are required by every major compliance framework—SOX, ISO 27001, and PCI DSS—when SAP systems are in scope.

SAP Fiori Role-Based Access Control (RBAC)

The first line of defense is granular RBAC using SAP Fiori Catalogs and Groups. Every Fiori app must be assigned to a specific catalog, and every catalog must be restricted by job function using PFCG roles. The common mistake is assigning the SAP_ALL or SAP_NEW roles to Fiori users—this bypasses all Launchpad-level authorization checks. Instead, use derived roles that inherit only the required authorization objects for each app.

For segregation of duties (SoD) compliance, every Fiori role assignment should be validated against a conflict check. For example, a user with access to both "Create Purchase Order" and "Approve Purchase Order" apps is a classic SoD violation that requires compensating controls or role re-certification.

Enforcing TLS and Authentication

All Fiori Launchpad traffic must be encrypted via HTTPS. This includes the frontend web server (SAP Web Dispatcher or reverse proxy) and the backend ABAP application server. In addition to TLS, enforce SAML 2.0 single sign-on (SSO) with multi-factor authentication (MFA) at the identity provider level. Fiori Launchpad supports SPNego/Kerberos for Windows-integrated environments and SAML 2.0 for cloud and hybrid scenarios.

OData Service Hardening

OData services must be explicitly activated only for apps that require them. SAP provides transaction /IWFND/MAINT_SERVICE to manage OData service registrations. Disable unused services and restrict service access to specific system aliases. Additionally, implement OData payload size limits and query parameter filtering in the SAP Gateway to prevent injection-based denial-of-service (DoS) attacks.

Detecting and Blocking Web Attacks on Fiori Launchpad

Baseline controls reduce the attack surface but cannot stop determined attackers in real time. This is where continuous detection and response becomes essential, especially for enterprises subject to SOX or PCI DSS audit requirements that mandate logging and monitoring of all SAP access.

Real-Time OData and HTTP Log Monitoring

Every Fiori request generates entries in the SAP ICM log and the Gateway error log (transaction /IWFND/ERROR_LOG). Monitoring these logs in real time allows security teams to detect:

• Repeated failed OData calls indicative of enumeration attacks
• Unusually large payloads suggesting data exfiltration attempts
• Requests to hidden or deactivated service endpoints
• Geolocation anomalies in user access patterns

While manual log review is impractical at scale, a solution like CyberSilo SAP Guardian ingests these logs and correlates them with SAP authorization data, user master records, and change documents to surface actionable alerts. For example, a user accessing a Fiori app outside their assigned roles triggers an immediate authorization violation alert tied to the specific OData call.

ABAP HTTP Whitelist Enforcement

SAP NetWeaver and S/4HANA allow administrators to define a whitelist of trusted web origins via transaction SM30 and view VSCAN_SERVER. This prevents HTTP request smuggling and host header injection attacks. Every Fiori app should validate the Origin and Referer headers against this whitelist before processing the request. Misconfigurations here are common— verify that the whitelist excludes all untrusted domains and does not contain wildcards.

CSRF Token Validation and Enforcement

SAP Gateway enforces CSRF protection by default when the profile parameter icf/csrf_token_expiration is set to a non-zero value. However, custom Fiori apps developed outside the SAP standard framework sometimes bypass this token check. Run the report RS_CSRF_TOKEN_CHECK to audit all OData services and identify those not enforcing token validation. For every service that fails this check, apply the missing configuration or deprecate the app until remediation is complete.

Insider Threat Detection in Fiori Environments

External attackers get headlines, but insider threats—whether malicious or negligent—account for the majority of SAP data breaches. Fiori Launchpad's user-friendly interface can mask anomalous behavior that would be obvious in traditional SAP GUI sessions.

Monitoring Authorization and SoD Violations

When a user with "Display Only" roles suddenly executes an update or create transaction through a Fiori app, the activity should trigger an immediate alert. This requires cross-referencing the executed transaction code with the user's authorization profile at runtime. SAP's standard audit log (transaction SM19/SM20) captures transaction starts, but does not correlate them with authorization objects. A dedicated SAP security monitoring product ingests this data and applies contextual rules—for example, flagging any purchase order creation by a user not assigned to the SAP_MM_BUYER role.

Change Monitoring in Fiori Catalogs

One of the most overlooked security gaps is unauthorized changes to Fiori Catalog assignments. When an administrator adds a sensitive app (such as "Display Salary Data" or "Bank Account Maintenance") to a catalog used by a large user group, the change can go unnoticed for months. SAP Change Document logging (object S_CUS) must be activated for PFCG role changes and Fiori Catalog maintenance. These logs feed into automated monitoring that compares catalog assignments against the baseline and alerts on any additions or modifications.

For organizations seeking a pre-built monitoring framework that covers these exact scenarios, CyberSilo SAP Guardian includes dedicated rules for Fiori catalog drift, OData privilege escalation, and real-time SoD violation detection across S/4HANA and BTP.

Incident Response Workflow for Fiori Attacks

When an attack on Fiori Launchpad is detected, response speed determines whether the incident becomes a footnote or a disclosure event. The following workflow is aligned with NIST SP 800-61 and adapted for SAP-specific attack vectors.

Comparison of SAP Fiori Security Approaches

Organizations typically evaluate three approaches to securing Fiori Launchpad: manual hardening reliant on SAP Notes, standard SIEM integration with custom parsers, and dedicated SAP security monitoring platforms. The table below compares these approaches across key operational criteria.

As the comparison shows, a dedicated platform eliminates the manual overhead of parsing SAP-specific logs into a generic SIEM schema. For organizations using top 10 SIEM tools, the SAP Guardian integrates as a data source that normalizes SAP logs into the SIEM's native format, preserving the investment in the existing security operations center (SOC) while adding SAP-specific correlation rules.

Securing SAP Fiori on BTP and S/4HANA Cloud

The attack surface shifts when Fiori is deployed on SAP Business Technology Platform (BTP) or S/4HANA Cloud, Public Edition. In these environments, the infrastructure layer is managed by SAP, but application-level security remains the customer's responsibility.

BTP Role Collections and Destination Security

On BTP, Fiori Launchpad is served through the Cloud Foundry or Kyma runtime. Access is controlled via BTP Role Collections, which map to Cloud Foundry scopes. The critical security gap here is destination configuration: BTP destinations pointing to on-premise S/4HANA systems often store credentials that are reused across apps. Each Fiori app should use a dedicated destination with the minimum required OData service access, and destinations must be encrypted using BTP's Secure Store service.

Identity Authentication and Single Sign-On

For S/4HANA Cloud, SAP enforces SAML 2.0-based SSO through SAP Cloud Identity Services. The security team must enforce conditional access policies—such as requiring MFA for Fiori apps that access sensitive business objects like "Display Bank Account Details" or "Create Supplier Invoice." Without these policies, a compromised identity provider session gives the attacker full access to all Fiori apps assigned to the user.

Monitoring these cloud environments requires integration with BTP's Audit Log service and the Cloud Management Cockpit's access logs. CyberSilo SAP Guardian provides connectors for BTP audit logs, enabling the same correlation rules used for on-premise Fiori to extend into cloud-native deployments.

Common Misconfigurations That Enable Fiori Attacks

Based on security assessments conducted across dozens of SAP landscapes, the following misconfigurations appear most frequently in environments that experience Fiori incidents.

Overly Permissive ICF Service Nodes

The Internet Communication Framework (ICF) controls HTTP access to SAP services. When a new Fiori app is deployed without hardening its ICF node, the service inherits default permissions that may allow anonymous access. Run transaction SICF and review each service node assigned to Fiori—verify that "Logon Procedure" is set to "Required" and "SSL Required" is enabled. Any node set to "Standard" or "Anonymous" without explicit business justification should be corrected immediately.

Exposed Root Services in ICF

Some SAP landscapes inadvertently expose the root ICF service node /sap/opu/odata/ to the internet without sub-path restrictions. This allows attackers to enumerate all registered OData services. Restrict the root node to internal networks only and explicitly enable only the specific services required by deployed Fiori apps.

Disabled Security Audit Logging

Despite being a SOX requirement for in-scope systems, many S/4HANA instances disable security audit logging for Fiori transactions to reduce database growth. This creates a blind spot that both attackers and auditors can exploit. Enable auditing for all transaction groups relevant to Fiori—especially DSO (Data Selection), AUW (Authorization Changes), and CFC (Transaction Start)—and configure the logs for daily archiving into your SIEM or SAP security platform. Without this data, post-incident forensics are severely limited.

Building a Fiori Security Roadmap

Organizations that treat Fiori security as a one-time project rather than an ongoing program frequently experience audit findings and, in some cases, actual breaches. The following roadmap aligns with common maturity models and compliance timelines.

Phase 1 (0-30 days): Baseline and Audit. Conduct a Fiori Launchpad security audit using SAP's standard tools—transactions SUIM for user analysis, /IWFND/MAINT_SERVICE for OData exposure, and SICF for ICF hardening. Document all gaps and prioritize by risk level.

Phase 2 (30-90 days): Hardening and Monitoring. Apply the baseline controls described in this article: RBAC enforcement, TLS hardening, CSRF token validation, and OData whitelisting. Deploy a monitoring solution that captures OData calls, authorization changes, and catalog modifications. Begin logging to a central security repository.

Phase 3 (90-180 days): Continuous Monitoring and Incident Response. Establish runbooks for the most common Fiori attack scenarios. Implement automated alerting for authorization violations and catalog drift. Integrate SAP logs with the broader SOC workflow, ensuring that the SAP team receives escalated alerts within the existing incident management system.

Throughout this process, cross-reference your controls against the top 10 compliance automation tools to streamline evidence collection for SOX, ISO 27001, and PCI DSS audits. Automated evidence gathering reduces auditor time by up to 50% and eliminates the manual effort of collecting SAP security logs on demand.