Sicherheit von View-Context-Daten 
Zentraler Bestandteil jeder Web-Dynpro-Anwendung sind die Daten, die im View-Context gehalten und verarbeitet werden. Die UI-Elemente, die über den View Designer für die entsprechende View definiert wurden, werden in der Regel vom Web-Dynpro-Anwendungsentwickler an die einzelnen View-Context-Elemente gebunden, damit ein Datenfluss zwischen Client und Server stattfinden kann.
View-Context-Daten können jedoch auch ungebunden im View-Context stehen, zum Beispiel, wenn eine ABAP-Dictionary-Struktur verwendet wird, die weitere Attribute enthält, welche nicht visualisiert werden. Eine generelle und sichere Variante, Context-Attribute durch Änderungen vom Client zu schützen ist es, die READ_ONLY-Eigenschaft an der Context-Attribute-Info (IF_WD_CONTEXT_NODE_INFO) auf ABAP_TRUE zu setzen. Die Einstellungen eines individuellen Context-Attributes über die Context-Attribute-Properties wird jedoch nicht ausgewertet.
Das Entfernen eines Context-Attributes aus dem View-Designer hat bei gemappten Context-Knoten und Context-Knoten mit DDIC-Bindung keinerlei positiven Effekt auf die Sicherheit. Diese Attribute sind dann in der Workbench nicht mehr sichtbar, können aber über dynamische Programmierung weiterhin verwendet werden.
Empfehlung
SAP empfiehlt, dass der View-Context nur die Daten enthalten sollte, die für die spezielle View notwendig sind. Damit kann ein Zugriff durch den Client von vornherein ausgeschlossen werden. Außerdem kann ein solches Design die Performance verbessern, weil die Datenhaltung im Context einen größeren Overhead hat als eine interne Tabelle und sich durch unnötiges Mapping von Context-Knoten die Effizienz des view-basierten Delta Renderings verschlechtern kann.
Für die Absicherung auf schreibenden Zugriff auf den Context gilt folgendes:
Beim Zugriff auf Daten des View-Contexts vom Client aus prüft das Web Dynpro Framework , ob ein Context-Attribut über ein UI-Element momentan sichtbar ist. Eine Verletzung führt zum Kurzdump
Bei Exponierung von Daten über den View-Context prüft das Web Dynpro Framework , ob ein Context-Attribut vorhanden und änderbar ist. Eine Verletzung führt zum Kurzdump
Bei der Datentyp-Prüfung prüft das Web Dynpro Framework , ob die Eingabe in Bezug auf den Datentyp des Attributs gültig ist. Eine Verletzung führt zur Fehlermeldung.
Für alle UI-Elemente, die änderbare Werte haben, muss der Anwendungsentwickler selbst prüfen, welche Änderungen erlaubt sind und damit unerlaubte Zugriffe auf die Businesslogik verhindern.
Das Web Dynpro HTML Rendering stellt sicher, das ausschließlich Context-Attribute am Client dargestellt und vom Client verändert werden können, für die dies erlaubt ist.
Das bedeutet im Detail:
Nur wenn ein Context-Attribut an eine Eigenschaft eines UI-Elements gebunden ist und das UI Element gerade sichtbar ist, wird der Wert des Context-Attributs an den Client transportiert.
Beispiel: Die Eigenschaft TextView.text ist an ein Context-Attribut DATA.AIRLINE gebunden. Ist das UI Element sichtbar, so wird der Wert aus dem Attribut DATA.AIRLINE gelesen und als TextView Text an den Client gesendet.
Nur wenn ein Context-Attribut an eine Eigenschaft eines UI-Elements gebunden ist, das UI-Element gerade sichtbar ist und der Wert bei der aktuellen Einstellung änderbar ist, so kann der Wert eines Context-Attributs verwendet werden.
Beispiel: Die EigenschaftTextView.text ist an ein Context-Attribut DATA.AIRLINE gebunden. Ist das UI-Element sichtbar, so wird der Wert aus dem Attribut DATA.AIRLINE gelesen und als TextView Text an den Client gesendet. Da die Eigenschaft text jedoch keine Änderung durch den Benutzer zulässt, verhindert das Framework, dass das Attribut vom Client verändert wird.
Beispiel: Die Eigenschaft InputField.value ist an ein Context-Attribut DATA.AMOUNT gebunden. Ist das UI-Element sichtbar, so wird der Wert aus dem Attribut DATA.AMOUNT gelesen und der Wert kann durch den Client verändert werden. Ist jedoch die Eigenschaft InputField.enabled auf false oder InputField.readOnly auf true gesetzt, so kann das Attribut nicht vom Client verändert werden.
Weiterhin ist zu beachten, dass alle Eingaben immer geprüft werden müssen. Web Dynpro bietet bereits eine eingebaute Prüfung auf Typ-Sicherheit. Zusätzlich muss eine Anwendung jedes veränderte Attribut auf seine semantische Korrektheit hin untersuchen und die Eingabe gegebenenfalls ablehnen. Dazu gehören auch Prüfungen auf bestimmte Arten von Attacken, z.B. SQL-Attacken, wenn eine Eingabe später in einem dynamischen SQL-Statement verwendet wird.