Signatur
Beschreibung
Die schreibgeschützte Eigenschaft sessionStorage der Schnittstelle StorageAccessHandle liefert ein Storage-Objekt. Über dieses Objekt kann ein eingebettetes Dokument in einem Drittanbieter-Kontext (z. B. einem <iframe>) auf den nicht partitionierten Sitzungsspeicher seines eigenen Origins zugreifen. Das ist derselbe Speicher, den die Seite auch sieht, wenn sie selbst als Hauptseite geöffnet ist.
Ohne Storage-Zugriff bekommen eingebettete Inhalte Dritter in modernen Browsern nur einen partitionierten Speicher. Dieser ist an die jeweilige Hauptseite gebunden. Möchte ein Widget, etwa ein Login- oder Chat-Dienst, Sitzungsdaten zwischen seiner eigenen Seite und der eingebetteten Ansicht teilen, fordert es mit document.requestStorageAccess({ sessionStorage: true }) Zugriff an. Das zurückgegebene Promise wird mit einem StorageAccessHandle erfüllt. Dessen sessionStorage-Eigenschaft verwenden Sie dann statt window.sessionStorage.
Die Schnittstelle des zurückgegebenen Objekts ist die gewohnte Storage-API: getItem(), setItem(), removeItem(), clear(), key() und length. Die Daten bleiben nur für die Dauer der Browser-Sitzung (des Tabs) erhalten. Das globale window.sessionStorage bleibt dabei weiterhin partitioniert.
Rückgabewert
Storage-Objekt für den nicht partitionierten Sitzungsspeicher. Wenn beim Aufruf von requestStorageAccess() nicht sessionStorage: true (oder all: true) angegeben wurde, wird beim Lesen der Eigenschaft eine DOMException vom Typ SecurityError geworfen.Beispiele
Nicht partitionierten sessionStorage anfordern und nutzen
// Läuft in einem Drittanbieter-iframe, z. B. nach einem Klick auf "Anmelden"
const button = document.querySelector('#login');
button.addEventListener('click', async () => {
try {
const handle = await document.requestStorageAccess({ sessionStorage: true });
handle.sessionStorage.setItem('widgetState', JSON.stringify({ step: 2 }));
console.log(handle.sessionStorage.getItem('widgetState'));
} catch (err) {
console.warn('Storage-Zugriff verweigert:', err.name);
}
});SecurityError, wenn sessionStorage nicht angefordert wurde
const handle = await document.requestStorageAccess({ localStorage: true });
try {
// sessionStorage wurde NICHT angefordert
handle.sessionStorage.getItem('foo');
} catch (err) {
console.log(err instanceof DOMException, err.name);
}
// localStorage funktioniert dagegen
handle.localStorage.setItem('theme', 'dark');Featureerkennung mit Rückfall auf partitionierten Speicher
const getSessionStore = async () => {
if (!('requestStorageAccess' in document)) return window.sessionStorage;
try {
const handle = await document.requestStorageAccess({ sessionStorage: true });
// Ältere Implementierungen liefern undefined statt eines Handles
return handle?.sessionStorage ?? window.sessionStorage;
} catch {
return window.sessionStorage; // partitioniert, aber nutzbar
}
};
document.querySelector('#start').addEventListener('click', async () => {
const store = await getSessionStore();
store.setItem('visited', 'yes');
console.log(store.getItem('visited'));
});// Wichtig · Fallstricke
- Browser-Unterstützung: Die erweiterte Form von
requestStorageAccess(types)mit Rückgabe einesStorageAccessHandlegibt es derzeit nur in Chromium-Browsern (ab Chrome/Edge 125). Firefox und Safari kennen nur die einfache Form. Sie gewährt ausschließlich Zugriff auf Cookies, und das Promise wird mitundefinederfüllt. Deshalb immer mit Featureerkennung und optionaler Verkettung (?.) arbeiten. - SecurityError: Die Eigenschaft wirft einen Fehler, wenn
sessionStorage(oderall) nicht im Optionsobjekt stand. Die Zugriffe gehören daher in einentry/catch-Block. - Nutzeraktivierung:
requestStorageAccess()braucht in der Regel eine Nutzergeste, z. B. einen Klick. Außerdem muss der Nutzer den Drittanbieter vorher als Hauptseite besucht haben. Sonst wird das Promise abgelehnt. - Nicht mit
window.sessionStorageverwechseln: Das globale Objekt bleibt auch nach gewährtem Zugriff partitioniert. Nur das Objekt aus dem Handle greift auf den nicht partitionierten Speicher zu. - Sicherheit: Legen Sie im Sitzungsspeicher keine sensiblen Daten wie Tokens im Klartext ab. Jedes Skript im selben Origin kann ihn lesen, daher sind die Daten bei einer XSS-Lücke ungeschützt.