Skip to main content

Module 23: Security & Authorization in SAPUI5

Security in SAPUI5 is a shared responsibility between:

  • Frontend (UI behavior & visibility)
  • Backend (real authorization & data protection)

This module explains what UI5 can and cannot secure, and how to design secure, enterprise-ready applications.

1. Frontend vs Backend Security (Very Important)​

Golden Rule​

Critical Rule

SAPUI5 can NEVER enforce real security.
All real security must be enforced in the backend.

Responsibility Split​

LayerResponsibility
UI5 FrontendHide/disable UI elements
OData / RAPAuthorization checks
ABAP BackendData access control
Interview Gold

Say: “UI5 controls visibility, backend controls access.”

2. Role-Based UI Control​

Why Role-Based UI?​

  • Improve UX
  • Avoid showing irrelevant actions
  • Reduce user errors

Common Role-Based Scenarios​

  • Hide Admin buttons
  • Disable Edit for display users
  • Show actions conditionally

Role-Based Visibility (Model-Based)​

<Button
  text="Approve"
  visible="{auth>/canApprove}" />
var oAuthModel = new sap.ui.model.json.JSONModel({
  canApprove: true
});
this.getView().setModel(oAuthModel, "auth");
Best Practice

Drive UI visibility using models, not hardcoded logic.

3. OData Authorization Handling​

Where Authorization Happens​

  • In ABAP OData service
  • In RAP behavior definitions
  • In CDS authorization annotations

What UI5 Must Do​

  • Handle authorization errors
  • Display meaningful messages
  • Not expose restricted data

Authorization Error Example (403)​

error: function (oError) {
  if (oError.statusCode === 403) {
    sap.m.MessageBox.error("You are not authorized");
  }
}
Real Projects

Authorization failures are common — handle them gracefully.

4. Hide vs Restrict Functionality​

Hide (Frontend)​

  • Hides UI elements
  • Improves UX
  • NOT secure
<Button visible="{= ${auth>/isAdmin} }" />

Restrict (Backend)​

  • Enforces security
  • Mandatory
  • Non-negotiable
AUTHORITY-CHECK OBJECT 'Z_SALES'
  ID 'ACTVT' FIELD '02'.
Interview Trap

Hiding a button ≠ securing an action.

5. CDS-Based Authorization (Intro)​

CDS Authorization Concept​

@AccessControl.authorizationCheck: #CHECK
define view ZI_SalesOrder as select from ZSO_HDR
  • Authorization enforced at DB level
  • UI5 automatically respects it
SAP Strategy

CDS-based authorization is preferred in S/4HANA.

6. Security Best Practices (UI5)​

UI5 Security Do’s​

Follow These
  • Always handle 401 / 403 errors
  • Never trust UI-only checks
  • Use HTTPS always
  • Sanitize user inputs
  • Use CSRF token handling (auto in UI5)

UI5 Security Don’ts​

Avoid These
  • Hardcoding roles in UI
  • Storing sensitive data in models
  • Relying on visibility for security
  • Bypassing backend checks

7. Common Security Scenarios​

Scenario: Unauthorized Action​

User clicks Approve
  ↓
OData call
  ↓
Backend rejects (403)
  ↓
UI shows friendly message

Scenario: Unauthorized Data​

  • Backend filters data
  • UI receives only allowed records
Key Insight

UI5 should never receive unauthorized data.

8. Security in Freestyle UI5 vs Fiori Elements​

AspectFreestyle UI5Fiori Elements
UI ControlManualAnnotation-driven
AuthorizationBackendCDS/RAP
Risk of MistakesHigherLower
SAP Recommendation

Fiori Elements + RAP reduces security risks.

9. Interview-Grade Explanation​

Q: How do you handle security in SAPUI5 applications?

Answer:

Security is enforced in the backend via OData, CDS, or RAP. The UI5 frontend only controls visibility and user experience. I handle authorization errors gracefully in the UI and never rely on frontend logic for real access control.

10. Summary​

  • UI5 cannot enforce real security
  • Backend authorization is mandatory
  • UI role-based control improves UX
  • Hide ≠ Restrict
  • Handle OData authorization errors
  • Follow SAP security best practices

11. What’s Next?​

➡️ Module 24: Deployment, Transports & CI/CD for UI5

Learning Tip

If security is wrong, everything else is irrelevant.