SAMESITECOOKIESETTING - Detailbeschreibung

Überblick

Parameter: SAMESITECOOKIESETTING
Kategorie: Custom
Standardwert: Lax
Produkt: eTASK.Sonstige (Custom)

Was macht dieser Parameter?

Der Parameter legt das SameSite-Attribut fest, das Browser steuert, wann Cookies bei HTTP-Anfragen mitgesendet werden. Das SameSite-Attribut bestimmt, ob Cookies auf einen Erstanbieter-Kontext (Same-Site) beschränkt werden oder auch bei Cross-Site-Anfragen mitgesendet werden dürfen. Dies schützt vor Cross-Site Request Forgery (CSRF) Angriffen.

Wofür wird dieser Parameter verwendet?

Schutz vor Cross-Site Request Forgery (CSRF) Angriffen
Kontrolle darüber, wann Browser Cookies an den Server senden
Verhinderung ungewollter Aktionen durch bösartige externe Websites
Balance zwischen Sicherheit und Funktionalität bei Cross-Site-Anfragen
Erfüllung moderner Web-Sicherheitsstandards
Schutz der Benutzer-Sessions vor unbefugter Verwendung

Technische Details (für Administratoren)

Format: Text (String)
Standardwert: Lax

Gültige Werte:

Lax = Cookies werden bei Top-Level-Navigation mitgesendet (z.B. Klick auf Link), aber nicht bei eingebetteten Ressourcen (Standard, empfohlen)
Strict = Cookies werden nur bei Anfragen von der gleichen Website mitgesendet (höchste Sicherheit, kann Funktionalität einschränken)
None = Cookies werden bei allen Anfragen mitgesendet, auch Cross-Site (erfordert HTTPS und Secure-Flag)

Wichtige Hinweise:

Das SameSite-Attribut wird bei allen vom Portal gesetzten Cookies angewendet
Änderungen werden sofort wirksam, kein Portal-Neustart erforderlich
Der Wert ist nicht case-sensitive (Lax, lax, LAX werden gleich behandelt)
Bei ungültigen Werten wird automatisch der Standardwert "Lax" verwendet
Der Parameter wirkt sich auf alle Benutzer des Portals aus

Zusammenspiel mit anderen Parametern:

SECURECOOKIESETTING: Steuert das Secure-Flag der Cookies (nur über HTTPS) 📄 SECURECOOKIESETTING - Detailbeschreibung
CONTENTSECURITYPOLICY: Definiert weitere Sicherheitsrichtlinien für das Portal 📄 CONTENTSECURITYPOLICY - Detailbeschreibung IC2874
REFERRERPOLICY: Steuert Weitergabe von Referrer-Informationen 📄 REFERRERPOLICY - Detailbeschreibung

Bedeutung der Werte im Detail:

Lax (Standard):

Cookies werden mitgesendet bei: Direkter Navigation zur Website (z.B. Klick auf Link in E-Mail)
Cookies werden NICHT mitgesendet bei: Eingebetteten Inhalten, AJAX-Anfragen von anderen Domains, iframes
Beispiel: Ein Benutzer klickt in einer E-Mail auf einen Link zum Portal - Session-Cookie wird mitgesendet, Benutzer bleibt angemeldet

Strict:

Cookies werden NUR mitgesendet bei: Anfragen, die direkt von der Portal-Domain kommen
Cookies werden NICHT mitgesendet bei: Jeglicher Cross-Site-Navigation
Beispiel: Ein Benutzer klickt in einer E-Mail auf einen Link zum Portal - Session-Cookie wird NICHT mitgesendet, Benutzer muss sich neu anmelden

None:

Cookies werden IMMER mitgesendet, auch bei Cross-Site-Anfragen
Erfordert: HTTPS und Secure-Flag (SECURECOOKIESETTING = 1)
Verwendung: Nur wenn das Portal in iframes auf anderen Domains eingebettet werden muss

Wann sollten Sie diesen Wert ändern?

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

Ein ausgewogenes Verhältnis zwischen Sicherheit und Benutzerfreundlichkeit gewünscht ist
Benutzer nach Klick auf Links in E-Mails angemeldet bleiben sollen
Keine spezifischen Anforderungen für strengere oder lockerere Einstellungen vorliegen
Das Portal standard-konform betrieben werden soll

Wert auf "Strict" ändern, wenn:

Höchste Sicherheitsanforderungen bestehen
CSRF-Schutz maximiert werden soll
Benutzer sich bei jedem Zugriff über externe Links neu anmelden sollen
Das Portal nie über Cross-Site-Links aufgerufen werden soll
Compliance-Vorgaben strengste Sicherheitsmaßnahmen fordern

Achtung: Bei "Strict" müssen sich Benutzer nach Klick auf Links in E-Mails neu anmelden.

Wert auf "None" ändern, wenn:

Das Portal in iframes auf anderen Domains eingebettet werden muss
Integration mit externen Systemen Cookie-Übertragung erfordert
Cross-Site-Authentifizierung notwendig ist
HTTPS aktiv ist (zwingend erforderlich für "None")

Wichtig: "None" sollte nur verwendet werden, wenn technisch notwendig. HTTPS und SECURECOOKIESETTING = 1 sind Voraussetzung.

Wert NICHT ändern, wenn:

Das aktuelle Verhalten zufriedenstellend ist
Keine konkreten Anforderungen vorliegen
Sie nicht genau verstehen, welche Auswirkungen dies hat

Wichtige Hinweise

Standard ist optimal für die meisten Szenarien
Der Wert "Lax" bietet guten Schutz vor CSRF-Angriffen bei gleichzeitiger Benutzerfreundlichkeit. Links in E-Mails funktionieren wie erwartet.
"Strict" kann Benutzerfreundlichkeit beeinträchtigen
Bei Verwendung von "Strict" müssen sich Benutzer nach jedem Klick auf externe Links neu anmelden. Dies betrifft z.B. Links in E-Mail-Benachrichtigungen, Favoriten oder Lesezeichen.
"None" erfordert HTTPS
Der Wert "None" funktioniert nur, wenn das Portal über HTTPS läuft und SECURECOOKIESETTING = 1 ist. Browser blockieren andernfalls die Cookies.
Bestehende Cookies bleiben unverändert
Bereits im Browser gespeicherte Cookies werden nicht rückwirkend geändert. Die neue Einstellung gilt nur für neu gesetzte Cookies.
Browser-Unterstützung
Alle modernen Browser unterstützen das SameSite-Attribut. Ältere Browser ignorieren unbekannte Attribute und verwenden ihr Standard-Verhalten.
CSRF-Schutz ist mehrschichtig
Das SameSite-Attribut ist eine wichtige Schutzmaßnahme, sollte aber nicht als alleiniger CSRF-Schutz betrachtet werden. Das Portal implementiert zusätzliche Anti-CSRF-Mechanismen.
Einbettung in iframes
Wenn das Portal in iframes auf anderen Domains angezeigt werden soll, muss SAMESITECOOKIESETTING auf "None" gesetzt werden. Andernfalls werden Session-Cookies blockiert und Benutzer können sich nicht anmelden.
Test nach Änderungen
Nach Änderungen sollten verschiedene Zugriffswege getestet werden: Direkte URL-Eingabe, Links in E-Mails, Favoriten, Single-Sign-On.

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 auf "None" setzen ohne HTTPS:

Browser blockieren Cookies ohne Secure-Flag
Portal-Funktionalität ist beeinträchtigt
Anmeldung funktioniert möglicherweise nicht

Wert auf "None" setzen ohne Notwendigkeit:

Cookies werden bei allen Cross-Site-Anfragen mitgesendet
Erhöhtes Risiko für CSRF-Angriffe
Bösartige Websites können Anfragen im Namen angemeldeter Benutzer stellen
Schutzwirkung des SameSite-Attributs wird aufgehoben

Wert auf "Strict" setzen ohne Vorbereitung:

Keine Sicherheitsrisiken, aber Benutzerfreundlichkeitseinbußen
Benutzer werden nach Klick auf externe Links abgemeldet
Erhöhter Support-Aufwand durch Rückfragen

Best Practice für Sicherheit:

Standard beibehalten - SAMESITECOOKIESETTING = "Lax"
Nur bei Bedarf ändern - "None" nur wenn technisch erforderlich (z.B. iframe-Einbettung)
HTTPS verwenden - Bei "None" zwingend erforderlich
Dokumentieren - Gründe für Abweichungen vom Standard festhalten
Testen - Nach Änderungen alle Zugriffswege prüfen

Compliance-Aspekte:

Das SameSite-Attribut ist relevant für:

OWASP Top 10 (A01:2021 - Broken Access Control)
Schutz vor CSRF-Angriffen
Moderne Web-Sicherheitsstandards
DSGVO (technische und organisatorische Maßnahmen)

Praktisches Beispiel

Ausgangssituation:

Ein Facility-Management-Unternehmen mit 500 Mitarbeitern betreibt eTASK FM seit 2 Jahren erfolgreich. Das Portal läuft über HTTPS und sendet automatisch E-Mail-Benachrichtigungen an Benutzer, z.B. bei neuen Aufgaben oder Statusänderungen.

Die IT-Abteilung führt ein Sicherheits-Audit durch und überprüft die Cookie-Konfiguration:

ASP.NET_SessionId: Secure, HttpOnly, SameSite=Lax
.ASPXAUTH: Secure, HttpOnly, SameSite=Lax

Der Parameter SAMESITECOOKIESETTING steht auf dem Standardwert "Lax".

Audit-Test 1 - Link in E-Mail:

Ein Benutzer erhält eine E-Mail-Benachrichtigung über eine neue Aufgabe mit Link zum Portal. Er klickt auf den Link und wird direkt zur Aufgabe geleitet, ohne sich neu anmelden zu müssen.

Ergebnis: Der Browser sendet das Session-Cookie mit, da es sich um Top-Level-Navigation handelt. "Lax" erlaubt dies.

Audit-Test 2 - Eingebettetes Bild von externer Domain:

Eine externe Website versucht, ein Bild vom Portal zu laden, das nur für angemeldete Benutzer sichtbar ist.

Ergebnis: Der Browser sendet das Session-Cookie NICHT mit, da es sich um eine Cross-Site-Anfrage handelt. "Lax" blockiert dies. Schutz funktioniert.

Audit-Ergebnis:

"Die Konfiguration ist optimal. Der Wert 'Lax' bietet guten Schutz vor CSRF-Angriffen und gewährleistet gleichzeitig, dass Benutzer über Links in E-Mails bequem auf das Portal zugreifen können. Keine Änderungen erforderlich."

Neue Anforderung - iframe-Einbettung:

Einige Wochen später möchte die Geschäftsführung das Portal in das Unternehmens-Intranet (SharePoint) einbetten, damit Mitarbeiter direkt im Intranet auf bestimmte Portal-Funktionen zugreifen können.

Das Intranet läuft auf einer anderen Domain: https://intranet.firma.de

Problem:

Der IT-Administrator bindet Seiten aus dem Portal per iframe ein:

<iframe src="https://etask.firma.de/Portal/Dashboard"></iframe>

Benutzer sehen nur eine Fehlermeldung oder Anmeldeseite im iframe, obwohl sie im Portal angemeldet sind.

Analyse:

Der Administrator prüft die Browser-Konsole:

"Cookie wurde blockiert, da SameSite=Lax"
Session-Cookies werden bei iframe-Einbettung nicht mitgesendet
SAMESITECOOKIESETTING = "Lax" verhindert Cross-Site-Cookie-Übertragung

Lösung:

Der Administrator ändert den Parameter:

SAMESITECOOKIESETTING auf "None" setzen
Prüfung: Portal läuft über HTTPS (erfüllt)
Prüfung: SECURECOOKIESETTING = 1 (erfüllt)

Nach der Änderung:

ASP.NET_SessionId: Secure, HttpOnly, SameSite=None
.ASPXAUTH: Secure, HttpOnly, SameSite=None

Das Portal funktioniert nun im iframe auf der Intranet-Seite. Angemeldete Benutzer können direkt auf Dashboard-Funktionen zugreifen.

Dokumentation:

Der Administrator dokumentiert die Änderung:

Parameter: SAMESITECOOKIESETTING = "None"
Grund: iframe-Einbettung im Unternehmens-Intranet
Datum: 2026-07-21
Voraussetzungen erfüllt: HTTPS aktiv, SECURECOOKIESETTING = 1

Ergebnis:

Portal funktioniert im Intranet-iframe
HTTPS und Secure-Flag schützen Cookies weiterhin
Integration erfolgreich
Mitarbeiterzufriedenheit durch nahtlose Integration

Alternative Lösung - Reverse Proxy:

Ein anderes Unternehmen mit ähnlicher Anforderung entschied sich gegen die Änderung auf "None". Stattdessen wurde ein Reverse Proxy eingerichtet, der beide Systeme unter einer gemeinsamen Domain verfügbar macht:

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

Vorteil: SAMESITECOOKIESETTING konnte bei "Lax" bleiben, da keine Cross-Site-Anfragen mehr nötig sind. Nachteil: Höherer Infrastruktur-Aufwand.

Empfohlene Einstellung

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

Begründung:

Guter Schutz vor CSRF-Angriffen
Benutzerfreundlichkeit bleibt erhalten (Links in E-Mails funktionieren)
Cookies werden nur bei sicheren Top-Level-Navigationen mitgesendet
Etablierter Standard für moderne Webanwendungen
Keine negativen Auswirkungen auf typische Portal-Nutzung

Für höchste Sicherheitsanforderungen: Strict

Nur wenn:

Maximaler CSRF-Schutz erforderlich ist
Benutzer sich bei jedem externen Zugriff neu anmelden sollen
Compliance-Vorgaben dies explizit fordern
Benutzer über Support informiert wurden

Für Cross-Site-Szenarien: None