Do Not Put the SAP Fiori Front-End Server on the Internet

The question arrives on every S/4HANA program that has field engineers, plant managers, external auditors or a sales force that will not install a VPN client. Someone needs the Fiori launchpad from outside the corporate network, and the design that gets proposed is almost always the same: publish the front-end server, put an SAP Web Dispatcher in the DMZ in front of it, buy a certificate, go live.

It is wrong, and the reason is narrower than the usual defense-in-depth argument. It is not that more layers are generally better. It is that the specific thing you are publishing is an ABAP application server, and the specific control that has protected SAP customers through the last four years of critical vulnerabilities was not patching. It was reachability.

What gets exposed

A Fiori front-end server is not a web server that happens to sit near SAP. It is a full ABAP application server that happens to serve a web application. Publishing it puts the Internet Communication Manager on the internet, and behind the ICM sits the whole Internet Communication Framework service tree.

Fiori itself needs about a dozen paths: the launchpad shell under /sap/bc/ui2/, UI5 resources under /sap/bc/ui5_ui5/, OData services under /sap/opu/odata/. A default S/4HANA front-end server has hundreds of ICF nodes active. The rest of the tree typically includes:

That last one hands over the reconnaissance step. Matching a kernel patch level against SAP's published notes is then bookkeeping.

The launchpad adds more. OData $metadata documents describe your entity sets, which is a readable map of the business functions the system offers. And unless you have changed it, the login form accepts basic authentication against the SAP user store with no second factor, at whatever rate the ICM will serve.

The login screen is not the boundary

Two SAP vulnerabilities show why "an attacker still has to authenticate" is the wrong model.

CVE-2022-22536, which Onapsis named ICMAD, is a memory pipe desynchronization flaw in the ICM. CVSS 10.0, exploitable by an unauthenticated attacker with a single crafted HTTP request, leading to session hijacking and system takeover. SAP patched it in February 2022. It affected NetWeaver ABAP and Java, the ABAP Platform, SAP Content Server and the SAP Web Dispatcher. CISA added it to the Known Exploited Vulnerabilities catalog that August.

CVE-2025-31324 is a missing authorization check in the NetWeaver Visual Composer metadata uploader, also CVSS 10.0. An unauthenticated POST to one endpoint uploaded a JSP web shell. SAP issued an out-of-band patch on 24 April 2025. Censys counted more than 7,500 exposed NetWeaver application servers and estimated that a majority of internet-facing Java stacks had the vulnerable component enabled. EclecticIQ later recovered an attacker's own log files listing 581 compromised systems and 1,800 further domains queued for targeting, attributed to China-nexus groups, hitting gas distribution, water utilities, medical device manufacturing and government ministries.

The dates are the point.

For a month, and arguably three, every internet-facing system with that component enabled was compromisable with no patch available, no signature to deploy and no advisory to read.

Visual Composer is a Java stack component, so this particular CVE is not a Fiori front-end server story. ICMAD is: it hit the ICM, which is exactly what you publish when you publish a Fiori server. The transferable part is the shape of the event, not the component. A pre-authentication remote code execution in an internet-facing SAP web stack, disclosed after weeks of exploitation.

Patching discipline would not have helped. Password policy would not have helped. The control that mattered was reachability. If an unauthenticated attacker cannot open a TCP connection to your ICM, a pre-authentication RCE in your ICM is a maintenance ticket rather than an incident.

What the Web Dispatcher does and does not do

SAP Web Dispatcher belongs in this architecture. It is not a security boundary on its own, and treating it as one is the most common design error in this area.

It also runs the same ICM code as the application servers behind it, which is why ICMAD affected it too. Onapsis noted that CVE-2022-22536 was exploitable specifically where a proxy sits between clients and backend, which describes every production landscape. The proxy layer is part of the attack surface, not outside it.

The architecture

The fourth layer is the one people struggle to name, which is part of why it gets left out. The term is authentication proxy, or pre-authentication reverse proxy. Vendors sell it as an identity-aware proxy, access gateway, web access management or ZTNA broker: Microsoft Entra ID Application Proxy, F5 BIG-IP APM, NetScaler Gateway, NetIQ Access Gateway. SAP's own version is Network Edge Authentication with SAP Single Sign-On, which has the Web Dispatcher perform the authentication step itself.

The identity mechanics are SAML 2.0. The front-end server is the Service Provider, the corporate IdP authenticates the user with MFA and conditional access applied there, and the redirect the user sees is the SAML HTTP-Redirect binding. Identity then travels inward by principal propagation: a short-lived X.509 certificate, a header variable, or an SAP logon ticket.

Two things follow. You can switch off form-based and basic authentication on the front-end server entirely, which removes the password oracle from the internet. And MFA becomes available at all, because SAP's own authentication stack does not provide a second factor for the launchpad. Moving authentication to the IdP means SAP inherits whatever your identity team builds, without an SAP project.

Configuration that has to follow

An architecture diagram is not a control. Each layer has a handful of settings that decide whether it does the job the diagram claims.

On the WAF, run the OWASP Core Rule Set in blocking mode rather than detection mode, rate-limit the authentication path, and confirm you have virtual patching. When the next HotNews note lands you want to block a path in hours, not wait for a kernel window.

On the authentication proxy, allow no anonymous pass-through on any path, including health checks and static resources. Enforce MFA for external networks, set a shorter session lifetime than you would internally, and log every request to the SIEM.

The Web Dispatcher is where I find the most gaps. Configure wdisp/permission_table as a deny-by-default allowlist that permits the Fiori paths and denies the rest explicitly. Set icm/HTTP/support_http2 deliberately. Add HSTS, X-Content-Type-Options and a Content-Security-Policy with a frame-ancestors directive, since a launchpad that can be framed can be clickjacked. Keep the kernel at or above the patch level of the systems behind it, and treat the host as an internet-facing asset for patching, not as Basis infrastructure.

On the front-end server, go through SICF and deactivate every service outside the Fiori scope, starting with WebGUI, SOAP RFC, ADT and /sap/public/info. Set is/HTTP/show_detailed_errors = FALSE to stop stack traces leaking. Set icf/set_HTTPonly_flag_on_cookies and login/ticket_only_by_https. Activate HTTP security session management with a sensible http/security_session_timeout. Then check that the active OData services are only those the published apps consume, because service activation is a decision nobody revisits. This is the same discipline as the rest of SAP platform hardening, applied to a host that has no margin for error.

The back end should be reachable from the front-end server over trusted RFC with a constrained user, and from nothing else. The protocol change does real work: OData in, RFC out, no HTTP path from edge to core. That is the strongest argument for hub deployment over embedded when the system is internet-facing, and it is worth reopening if your Fiori server is embedded in S/4HANA.

In the SIEM, ICM HTTP access logs and the ABAP security audit log both need to arrive, correlated with the authentication proxy logs. Without that correlation you cannot reconstruct what an authenticated session did once it was inside.

The BTP alternative

SAP Business Technology Platform avoids the exposure rather than mitigating it. SAP Build Work Zone hosts the launchpad, SAP Cloud Identity Services handles authentication, and SAP Cloud Connector links the on-premise system to the subaccount.

Cloud Connector establishes its tunnel by reverse invoke, so the connection opens outbound from inside your network. No inbound firewall rule, no published address, no listening service on the internet. The resource allowlist is enforced on your side of the tunnel, per path.

The trade-offs are real: dependency on BTP availability, subscription cost, and a Cloud Connector host that becomes a control point needing its own hardening and monitoring. For organizations already on BTP it is usually the better answer, and worth pricing before building the five-layer stack.

If you have inherited an exposed system

Do not patch first. Assume the window between exploitable and patched has already been used.

1. Check ICM access logs for requests to paths no legitimate Fiori app calls.
2. Look for files in the servlet and JSP directories nobody created.
3. Review users, role assignments and RFC destinations added since the last known-good state.
4. Run a compromise assessment. Onapsis and Mandiant published a joint tool during the CVE-2025-31324 response; the approach generalizes beyond that CVE.

Then patch, then close the exposure. Patching first destroys evidence and does nothing about a web shell already on disk.

Wording for the audit file

External access is brokered by an authentication reverse proxy performing pre-authentication against the corporate identity provider, and the SAP Fiori launchpad is not directly reachable from untrusted networks.

The control objectives behind it are ordinary. ISO 27001 Annex A requires network segregation and secure network services. NIS2 Article 21 requires network security and access control proportionate to the risk, and for entities in scope, an ERP system carrying order-to-cash sits inside that scope. Any auditor with SAP experience will ask what sits between the internet and the ICM. "The Web Dispatcher" is not an answer.

How MTC helps

We design and review SAP security architectures for regulated, multi-country landscapes from Geneva, including external Fiori access: ICF service tree reduction, Web Dispatcher and WAF configuration, pre-authentication proxy and SAML design, hub versus embedded deployment, BTP and Cloud Connector alternatives, and the log correlation an auditor will ask for. On large programs we work alongside leading global audit, risk and technology consulting firms, with the security outcome owned by a senior Swiss-based team.

Related reading

• SAP Security Consulting, our full SAP security scope
• SAP Cybersecurity: Hardening the SAP Platform, Not Just Access
• S/4HANA Migration: Greenfield vs Brownfield vs Selective
• IT General Controls (ITGC): A Practical Guide for Audit Readiness
• SAP GRC Access Control: What It Is and When You Need It

Frequently Asked Questions

Can you expose an SAP Fiori launchpad to the internet?

Not directly. A Fiori front-end server is a full ABAP application server, so publishing it puts the Internet Communication Manager and the whole Internet Communication Framework service tree within reach of unauthenticated attackers. External access should be brokered by a pre-authentication reverse proxy that authenticates the user against the corporate identity provider before any request reaches SAP, with a web application firewall in front of it and the SAP Web Dispatcher behind it. The alternative is SAP Build Work Zone on BTP with SAP Cloud Connector, which needs no inbound firewall rule at all.

Is the SAP Web Dispatcher a security boundary?

No, and treating it as one is the most common design error in external Fiori access. The Web Dispatcher terminates TLS, distributes load, hides internal hosts and ports, filters URLs against its permission table and gives the browser a single origin. It does not inspect payloads, rate-limit credential stuffing, enforce MFA or make any decision about who the user is; by default it forwards. It also runs the same ICM code as the application servers behind it, which is why CVE-2022-22536 affected the Web Dispatcher too. It belongs in the architecture, but as a reverse proxy, not as the thing standing between the internet and your ABAP stack.

What is an authentication proxy for SAP Fiori?

A reverse proxy that authenticates the user against the corporate identity provider before forwarding anything to SAP, so no anonymous request ever reaches the ABAP stack. Vendors sell it as an identity-aware proxy, access gateway, web access management or ZTNA broker: Microsoft Entra ID Application Proxy, F5 BIG-IP APM, NetScaler Gateway, NetIQ Access Gateway. SAP's own variant is Network Edge Authentication with SAP Single Sign-On, where the Web Dispatcher performs the authentication step itself. The identity mechanics are SAML 2.0, with the front-end server as Service Provider and identity traveling inward by principal propagation.

Which ICF services should be deactivated on an internet-facing Fiori front-end server?

Fiori itself needs roughly a dozen paths: the launchpad shell under /sap/bc/ui2/, UI5 resources under /sap/bc/ui5_ui5/ and OData services under /sap/opu/odata/. Everything else in the SICF tree should be reviewed and switched off, starting with /sap/bc/gui/sap/its/webgui (SAP GUI in a browser), /sap/bc/soap/rfc (RFC over SOAP), /sap/bc/webdynpro/, /sap/bc/adt (the ABAP development endpoint) and /sap/public/info, which returns the SID, kernel release, host name and time zone with no authentication at all. A default S/4HANA front-end server has hundreds of ICF nodes active.

What did CVE-2025-31324 change about SAP internet exposure?

It demonstrated the length of the window between exploitable and patchable. The flaw was a missing authorization check in the NetWeaver Visual Composer metadata uploader, CVSS 10.0, where an unauthenticated POST to a single endpoint uploaded a JSP web shell. Unit 42 observed probing in late January 2025, Rapid7 confirmed exploitation from at least 27 March, and SAP issued an out-of-band patch on 24 April. For a month, and arguably three, every internet-facing system with that component enabled was compromisable with no patch, no signature and no advisory. Patching discipline could not have helped; only reachability could.

Is SAP BTP a safer way to publish Fiori externally?

Usually yes, because it avoids the exposure rather than mitigating it. SAP Build Work Zone hosts the launchpad, SAP Cloud Identity Services handles authentication, and SAP Cloud Connector links the on-premise system to the subaccount by reverse invoke, so the tunnel opens outbound from inside your network. There is no inbound firewall rule, no published address and no listening service on the internet, and the resource allowlist is enforced on your side of the tunnel. The trade-offs are dependency on BTP availability, subscription cost, and a Cloud Connector host that becomes a control point needing its own hardening and monitoring.