SAP Fiori Security
Fiori security spans the frontend (who sees which apps) and the backend (who can run the services and access data), plus secure communication. Because Fiori exposes SAP over the web, getting its security right is essential.
Fiori access has two layers that must align: catalogs and groups in PFCG roles decide which apps appear, and backend authorisation objects checked by the OData services decide what data and actions are allowed. Enforce HTTPS for launchpad and OData traffic, activate only the ICF services an app needs, use SSO or MFA at the identity provider.
- Watch out: Over-granting backend authorizations.
The two layers of Fiori access
- Frontend: catalogs/groups in roles control which apps appear.
- Backend: authorization objects (checked by the OData services and CDS) control what data and actions are allowed.
Both must align
A secure, working setup grants a user exactly the apps they need (frontend) and exactly the backend authorizations those apps require, no more. Over-granting backend authorizations is a security risk; under-granting breaks the app. Least privilege applies to both layers.
Communication and platform security
- Enforce HTTPS/TLS for the launchpad and OData traffic.
- Secure the gateway and ICF services (only activate what is needed).
- Use SSO/MFA at the identity provider for authentication.
- Apply CDS access control (DCL) for row-level data authorization.
Why it matters
Fiori widens SAP’s exposure to browsers and mobile, so its attack surface must be controlled: least-privilege roles, only-needed services activated, encrypted transport, and proper authentication. Security review of Fiori apps is a standard part of go-live.
Common pitfalls
- Over-granting backend authorizations.
- Activating unnecessary services, widening the attack surface.
- HTTP instead of HTTPS for launchpad/OData.