XFRAMEOPTIONS - Detailbeschreibung – eTASK Support Center

Überblick

Parameter: XFRAMEOPTIONS
Kategorie: Custom
Standardwert: sameorigin
Produkt: eTASK.Sonstige (Custom)

Was macht dieser Parameter?

Der Parameter legt den HTTP-Antwort-Header X-Frame-Options fest, der bestimmt, ob eine Seite in einem <frame>, <iframe>, <embed> oder <object> dargestellt werden darf. Websites nutzen diesen Header, um Click-Jacking-Angriffe zu verhindern, indem sie sicherstellen, dass ihre Inhalte nicht in andere Websites eingebettet werden.

Wichtig: Jede Änderung des Standardwertes sameorigin kann dazu führen, dass das eTASK-Portal nicht mehr einwandfrei funktioniert.

Wofür wird dieser Parameter verwendet?

Schutz vor Click-Jacking-Angriffen - Verhindert, dass Angreifer das Portal in versteckten Frames auf fremden Websites einbetten
Sicherheitskontrolle für Frame-Einbettung - Bestimmt, welche Websites das Portal in Frames laden dürfen
Compliance mit Sicherheitsstandards - Erfüllt moderne Web-Sicherheitsanforderungen für Enterprise-Anwendungen
Schutz der Benutzerdaten - Verhindert, dass Benutzer durch gefälschte Oberflächen getäuscht werden
Integration mit Single-Sign-On - Ermöglicht kontrollierte Einbettung für SSO-Szenarien innerhalb derselben Domain
Verhinderung von UI-Redressing - Schützt vor Manipulationen der Benutzeroberfläche durch Überlagerung

Technische Details (für Administratoren)

Format: Text (String)
Standardwert: sameorigin

Gültige Werte:

deny = Die Seite kann niemals in einem Frame angezeigt werden, auch nicht auf derselben Website (höchste Sicherheit)
sameorigin = Die Seite kann nur in Frames auf derselben Domain angezeigt werden (Standard, empfohlen)
allow-from https://example.com = Die Seite kann nur von der angegebenen URL eingebettet werden (veraltet, nicht mehr empfohlen)

Wichtige Hinweise:

Der Header wird bei jeder HTTP-Antwort des Portals gesendet
Änderungen werden sofort wirksam, kein Portal-Neustart erforderlich
Der Header wird vom Browser ausgewertet und durchgesetzt
Nicht alle Browser unterstützen alle Werte gleich gut
allow-from ist veraltet und wird durch Content Security Policy (CSP) ersetzt
Der Parameter wirkt sich auf alle Seiten und Benutzer des Portals aus

Technische Implementierung:

Der Wert wird im HTTP-Header-Modul eTaskHeaderModule.cs gesetzt und bei jeder Antwort des Portals mitgesendet:

X-Frame-Options: sameorigin

Zusammenspiel mit anderen Parametern:

📄 CONTENTSECURITYPOLICY - Detailbeschreibung IC2874 : Definiert weitere Sicherheitsrichtlinien (frame-ancestors direktive ersetzt X-Frame-Options)

📄 CONTENTSECURITYPOLICYAKTIV - Detailbeschreibung IC2875 : Aktiviert die Content Security Policy (0/1/2)

CONTENTTYPEOPTIONSNOSNIFFACTIVE: Aktiviert zusätzlichen MIME-Type-Schutz (1/0)

Wann sollten Sie diesen Wert ändern?

Wert auf "deny" ändern, wenn:

Die Anwendung niemals in Frames eingebettet werden soll
Höchste Sicherheitsanforderungen bestehen (z.B. Finanzsysteme, Gesundheitswesen)
Die Anwendung ausschließlich als eigenständige Webanwendung verwendet wird
Keine Integration mit anderen Systemen über Frames erforderlich ist
Compliance-Vorgaben eine strikte Frame-Verbot fordern

Achtung: Dies kann bestehende Integrationen oder SSO-Mechanismen beeinträchtigen!

Wert auf "sameorigin" belassen (Standard), wenn:

Das Portal möglicherweise in eigene Frames eingebettet werden muss (z.B. Dashboard)
Single-Sign-On innerhalb der eigenen Domain verwendet wird
Integration mit anderen eTASK-Modulen über iframes erfolgt
Ein ausgewogenes Verhältnis zwischen Sicherheit und Flexibilität gewünscht ist
Keine spezifischen Anforderungen für strengere oder lockerere Einstellungen vorliegen

Wert NICHT ändern von "sameorigin", wenn:

Sie nicht genau verstehen, welche Auswirkungen dies hat
Keine konkreten technischen Anforderungen vorliegen
Das Portal derzeit problemlos funktioniert

Wichtige Hinweise

Standard nicht ohne Grund ändern
Der Standardwert sameorigin bietet einen ausgewogenen Schutz. Änderungen sollten nur nach sorgfältiger Analyse erfolgen, da sie die Portal-Funktionalität beeinträchtigen können.
"deny" kann Portal-Funktionen blockieren
Wenn Sie den Wert auf deny setzen, können Funktionen, die auf Frame-Einbettung angewiesen sind (z.B. integrierte Dashboards, eingebettete Berichte), nicht mehr funktionieren.
"allow-from" ist veraltet
Der Wert allow-from URL wird von modernen Browsern nicht mehr zuverlässig unterstützt. Verwenden Sie stattdessen die Content Security Policy direktive frame-ancestors über den Parameter CONTENTSECURITYPOLICY.
Browser-Unterstützung prüfen
Alle modernen Browser unterstützen X-Frame-Options, aber die Umsetzung kann variieren. Testen Sie Änderungen in allen von Ihnen verwendeten Browsern.
Click-Jacking-Schutz ist wichtig
Auch wenn das Risiko gering erscheint, bietet der Header wichtigen Schutz. Deaktivieren Sie ihn nicht ohne zwingenden Grund.
Kein Portal-Neustart erforderlich
Änderungen am Parameter werden sofort wirksam. Benutzer müssen lediglich die Seite neu laden (F5).
Kombination mit CSP empfohlen
Für maximale Sicherheit sollten Sie sowohl X-Frame-Options als auch die Content Security Policy direktive frame-ancestors verwenden. CSP hat bei Konflikten Vorrang.
Auswirkung auf externe Integrationen
Wenn Ihr Portal von externen Systemen (z.B. Portale von Partnern) in Frames eingebettet werden soll, verhindert der Standard-Wert sameorigin dies. Prüfen Sie Ihre Integrations-Anforderungen sorgfältig.
Logging und Monitoring
Browser-Konsolenmeldungen wie "Refused to display in a frame" weisen auf blockierte Frame-Einbettungen hin. Prüfen Sie diese bei Problemen.

Sicherheit

Hat eine Änderung dieses Parameters Auswirkungen auf die Sicherheit?

Ja, dieser Parameter hat direkte Auswirkungen auf die Sicherheit der Anwendung.

Sicherheitsrisiken bei falscher Konfiguration:

Wert entfernen oder auf leer setzen:

Kritisches Risiko - Das Portal ist anfällig für Click-Jacking-Angriffe
Angreifer können das Portal in versteckte Frames einbetten
Benutzer können getäuscht werden und ungewollt Aktionen ausführen
Sensible Daten können abgegriffen werden

Wert auf "allow-from" mit falscher URL setzen:

Mittleres Risiko - Veraltet und nicht mehr zuverlässig
Unvorhersehbares Verhalten in verschiedenen Browsern
Möglicherweise keine Schutzwirkung

Wert auf "deny" setzen (wenn nicht benötigt):

Keine Sicherheitsrisiken - Im Gegenteil, höchste Sicherheit
Funktionsrisiko - Kann Portal-Funktionen beeinträchtigen

Best Practice für Sicherheit:

Standard beibehalten - sameorigin ist für die meisten Szenarien optimal
Mit CSP kombinieren - Setzen Sie zusätzlich CONTENTSECURITYPOLICY mit frame-ancestors 'self'
Regelmäßig prüfen - Überwachen Sie Browser-Konsolenmeldungen auf blockierte Frame-Versuche
Dokumentieren - Halten Sie fest, warum Sie von der Standardeinstellung abweichen
Testen - Bei Änderungen alle Portal-Funktionen umfassend testen

Praktisches Beispiel

Ausgangssituation:

Ein mittelständisches Unternehmen mit 800 Mitarbeitern betreibt eTASK FM seit 3 Jahren erfolgreich. Die IT-Abteilung erhält zunehmend Anfragen von der Geschäftsführung, ob das Portal auch in das neu eingeführte Intranet-Portal (SharePoint) eingebettet werden kann, damit Mitarbeiter nicht zwischen verschiedenen Systemen wechseln müssen.

Das Intranet-Portal läuft auf der Domain https://intranet.firma.de, während eTASK auf https://etask.firma.de gehostet wird.

Problem:

Der IT-Administrator versucht, das eTASK-Portal in einem iframe auf der Intranet-Seite einzubetten:

<iframe src="https://etask.firma.de/Portal" width="100%" height="800px"></iframe>

Die Integration schlägt fehl. In der Browser-Konsole erscheint die Fehlermeldung:

Refused to display 'https://etask.firma.de/Portal' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

Das eTASK-Portal wird nicht angezeigt. Benutzer sehen nur einen leeren Frame.

Analyse:

Der Administrator überprüft die Systemkonfiguration und findet den Parameter XFRAMEOPTIONS mit dem Wert sameorigin. Dieser Wert erlaubt nur die Einbettung auf derselben Domain (etask.firma.de), nicht aber auf der Intranet-Domain (intranet.firma.de).

Lösungsoptionen evaluiert:

Option 1: Parameter auf leer setzen

Abgelehnt - Sicherheitsrisiko zu hoch
Würde Click-Jacking-Schutz komplett entfernen

Option 2: Parameter auf "allow-from https://intranet.firma.de" setzen

Abgelehnt - Veraltet und Browser-Support unzuverlässig
Funktioniert nicht in Chrome, Edge und modernen Browsern

Option 3: Content Security Policy verwenden

Gewählt - Moderne, sichere Lösung

Implementierte Lösung:

Der Administrator konfiguriert zwei Parameter:

XFRAMEOPTIONS bleibt auf sameorigin (für ältere Browser)

CONTENTSECURITYPOLICY wird erweitert mit:

frame-ancestors 'self' https://intranet.firma.de;

CONTENTSECURITYPOLICYAKTIV wird auf 1 gesetzt

Nach der Änderung:

Das Portal kann nun sowohl direkt aufgerufen werden als auch im Intranet-iframe angezeigt werden
Der Click-Jacking-Schutz bleibt aktiv - nur die Intranet-Domain ist erlaubt
Alle anderen Websites werden weiterhin blockiert
Kompatibilität mit allen Browsern gewährleistet

Ergebnis nach 3 Monaten:

Integration erfolgreich: 95% der Mitarbeiter nutzen das Portal über das Intranet
Keine Sicherheitsvorfälle
Single-Sign-On funktioniert reibungslos über beide Domains
Benutzerzufriedenheit: +30% (keine Mehrfachanmeldungen mehr nötig)
IT-Support-Anfragen wegen Anmeldeprobleme: -60%

Lessons Learned:

Das Team hat gelernt, dass:

X-Frame-Options allein nicht ausreicht für Cross-Domain-Szenarien
Content Security Policy die moderne Lösung ist
Beide Mechanismen kombiniert werden können für maximale Kompatibilität
Sicherheit und Benutzerfreundlichkeit sich nicht ausschließen müssen

Alternative Lösung - Reverse Proxy:

Ein anderes Unternehmen mit ähnlichen Anforderungen entschied sich für einen Reverse Proxy, der beide Systeme unter einer gemeinsamen Domain verfügbar macht:

https://portal.firma.de/etask     → eTASK FM
https://portal.firma.de/intranet  → SharePoint Intranet

Dadurch war keine Änderung an XFRAMEOPTIONS erforderlich, da beide Systeme dieselbe Domain verwenden. Diese Lösung erfordert jedoch mehr Infrastruktur-Aufwand.

Empfohlene Einstellung

Für Standard-Installationen: sameorigin (Standard beibehalten)

Begründung:

Bietet soliden Schutz vor Click-Jacking-Angriffen
Erlaubt flexible Verwendung innerhalb der eigenen Domain
Etablierter Industriestandard für Web-Anwendungen
Keine negativen Auswirkungen auf typische Portal-Funktionen
Breite Browser-Unterstützung

Für höchste Sicherheitsanforderungen: deny

Nur wenn:

Das Portal niemals in Frames eingebettet werden muss
Keine Integration mit anderen Systemen über iframes erfolgt
Compliance-Vorgaben dies explizit fordern
Alle Portal-Funktionen nach der Änderung getestet wurden

Für Cross-Domain-Integration: Content Security Policy verwenden

Statt XFRAMEOPTIONS zu ändern:

XFRAMEOPTIONS bei sameorigin belassen
CONTENTSECURITYPOLICY mit frame-ancestors konfigurieren
Nur spezifische, vertrauenswürdige Domains erlauben
Moderne und zukunftssichere Lösung

Niemals empfohlen:

Parameter leer lassen oder entfernen
allow-from verwenden (veraltet)
Wildcard-Werte verwenden
Ungesicherte HTTP-URLs erlauben

Best Practices:

Standard-Wert beibehalten - Nur bei dokumentiertem Bedarf ändern
Mit CSP kombinieren - frame-ancestors in CONTENTSECURITYPOLICY setzen
Whitelist-Prinzip - Nur bekannte, vertrauenswürdige Domains explizit erlauben
Regelmäßig überprüfen - Bei neuen Integrationsanforderungen Konfiguration anpassen
Dokumentieren - Jede Abweichung vom Standard mit Begründung festhalten
Testen - Nach Änderungen alle Portal-Funktionen überprüfen
Monitoring - Browser-Konsole auf blockierte Frame-Versuche überwachen

XFRAMEOPTIONS - Detailbeschreibung

Administration