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 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.
- A secure, working setup grants a user exactly the apps they need (frontend) and exactly the backend authorizations those apps…
- 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.
- 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.