Element: innerHTML-Eigenschaft
Baseline
Widely available
*
This feature is well established and works across many devices and browser versions. It’s been available across browsers since Juli 2015.
{"* "}Some parts of this feature may have varying levels of support.
Warnung: Diese Eigenschaft parst ihre Eingabe als HTML und schreibt das Ergebnis in den DOM. Solche APIs sind bekannt als Injection Sinks und können ein Vektor für Cross-Site-Scripting (XSS)-Angriffe sein, wenn die Eingabe ursprünglich von einem Angreifer stammt.
Sie können dieses Risiko mindern, indem Sie immer TrustedHTML
-Objekte statt Strings zuweisen und Trusted Types durchsetzen.
Weitere Informationen finden Sie unter Sicherheitsüberlegungen.
Die innerHTML
-Eigenschaft des Element
-Interfaces erhält oder setzt das HTML- oder XML-Markup innerhalb des Elements, wobei in beiden Fällen jegliche Shadow Roots ausgelassen werden.
Um das HTML in das Dokument einzufügen, anstatt den Inhalt eines Elements zu ersetzen, verwenden Sie die Methode insertAdjacentHTML()
.
Wert
Das Abrufen der Eigenschaft gibt einen String zurück, der die HTML-Serialisierung der Nachfahren des Elements enthält.
Die Einstellung der Eigenschaft akzeptiert entweder ein TrustedHTML
-Objekt oder einen String. Dieser Wert wird als HTML geparst und ersetzt alle Nachfahren des Elements mit dem Ergebnis.
Wenn der null
-Wert gesetzt wird, wird dieser null
-Wert in den leeren String (""
) umgewandelt, sodass elt.innerHTML = null
gleichbedeutend mit elt.innerHTML = ""
ist.
Ausnahmen
SyntaxError
DOMException
-
Wird ausgelöst, wenn versucht wird, den Wert von
innerHTML
mit einem String zu setzen, der kein korrekt formatiertes HTML ist. TypeError
-
Wird ausgelöst, wenn die Eigenschaft auf einen String gesetzt wird, während Trusted Types durch eine CSP erzwungen werden und keine Standardrichtlinie definiert ist.
NoModificationAllowedError
DOMException
-
Wird ausgelöst, wenn versucht wird, das HTML in einen Knoten einzufügen, dessen Elternteil ein
Document
ist.
Beschreibung
innerHTML
erhält eine Serialisierung der verschachtelten DOM-Kindelemente innerhalb des Elements oder setzt HTML oder XML, das geparst werden soll, um den DOM-Baum innerhalb des Elements zu ersetzen.
Beachten Sie, dass einige Browser die Zeichen <
und >
als <
und >
serialisieren, wenn sie in Attributwerten erscheinen (siehe Browser-Kompatibilität).
Dies soll eine potenzielle Sicherheitsanfälligkeit (Mutation XSS) verhindern, bei der ein Angreifer Eingaben erstellen kann, die eine Sanisierungsfunktion umgehen, wodurch ein Cross-Site-Scripting (XSS)-Angriff ermöglicht wird.
Überlegungen zum Shadow DOM
Die Serialisierung des vom Property gelesenen DOM-Baums schließt keine Shadow Roots ein — wenn Sie einen HTML-String erhalten möchten, der Shadow Roots enthält, müssen Sie stattdessen die Methoden Element.getHTML()
oder ShadowRoot.getHTML()
verwenden.
Ebenso, wenn der Elementinhalt unter Verwendung von innerHTML
gesetzt wird, wird der HTML-String in DOM-Elemente geparst, die keine Shadow Roots enthalten.
So wird zum Beispiel <template>
als HTMLTemplateElement
geparst, unabhängig davon, ob das shadowrootmode
-Attribut angegeben ist.
Um den Inhalt eines Elements aus einem HTML-String zu setzen, der deklarative Shadow Roots enthält, müssen Sie stattdessen Element.setHTMLUnsafe()
oder ShadowRoot.setHTMLUnsafe()
verwenden.
Sicherheitsüberlegungen
Die innerHTML
-Eigenschaft ist wahrscheinlich der häufigste Vektor für Cross-Site-Scripting (XSS)-Angriffe, bei denen potenziell unsichere Strings, die von einem Benutzer bereitgestellt werden, in den DOM injiziert werden, ohne vorher bereinigt zu werden.
Während die Eigenschaft verhindert, dass <script>
-Elemente ausgeführt werden, wenn sie injiziert werden, ist sie anfällig für viele andere Möglichkeiten, wie Angreifer HTML erstellen können, um bösartigen JavaScript auszuführen.
Ein Beispiel: Der folgende Code würde den Code im error
-Ereignishandler ausführen, weil der <img>
src
-Wert keine gültige Bild-URL ist:
const name = "<img src='x' onerror='alert(1)'>";
el.innerHTML = name; // shows the alert
Sie können diese Probleme mindern, indem Sie immer TrustedHTML
-Objekte statt Strings zuweisen und Verify Trusted Type mit der CSP-Direktive require-trusted-types-for
durchsetzen.
Dies stellt sicher, dass die Eingabe durch eine Transformationsfunktion geleitet wird, die die Möglichkeit hat, die Eingabe zu sanitieren, um potenziell gefährliches Markup zu entfernen, bevor es injiziert wird.
Hinweis:
Node.textContent
sollte verwendet werden, wenn Sie wissen, dass der vom Benutzer bereitgestellte Inhalt reiner Text sein sollte.
Dies verhindert, dass es als HTML geparst wird.
Beispiele
>Lesen des HTML-Inhalts eines Elements
Das Lesen von innerHTML
veranlasst den Benutzeragenten, die Nachfahren des Elements zu serialisieren.
Angesichts des folgenden HTML:
<div id="example">
<p>My name is Joe</p>
</div>
Sie können das Markup der Inhalte des äußeren <div>
wie folgt abrufen und protokollieren:
const myElement = document.querySelector("#example");
const contents = myElement.innerHTML;
console.log(contents); // "\n <p>My name is Joe</p>\n"
Ersetzen des Inhalts eines Elements
In diesem Beispiel werden wir ein DOM-Element ersetzen, indem wir HTML der innerHTML
-Eigenschaft des Elements zuweisen.
Um das Risiko von XSS zu mindern, erstellen wir zuerst ein TrustedHTML
-Objekt aus dem String, der das HTML enthält, und weisen dann dieses Objekt innerHTML
zu.
Trusted Types werden noch nicht von allen Browsern unterstützt, daher definieren wir zuerst das Trusted Types Tinyfill. Dieses funktioniert als transparenter Ersatz für die Trusted Types JavaScript API:
if (typeof trustedTypes === "undefined")
trustedTypes = { createPolicy: (n, rules) => rules };
Als nächstes erstellen wir eine TrustedTypePolicy
, die ein createHTML()
zum Umwandeln eines Eingabe-Strings in TrustedHTML
-Instanzen definiert.
In der Regel verwenden Implementierungen von createHTML()
eine Bibliothek wie DOMPurify, um die Eingabe wie unten gezeigt zu sanitieren:
const policy = trustedTypes.createPolicy("my-policy", {
createHTML: (input) => DOMPurify.sanitize(input),
});
Dann verwenden wir dieses policy
-Objekt, um ein TrustedHTML
-Objekt aus dem potenziell unsicheren Eingabestring zu erstellen und das Ergebnis dem Element zuzuweisen:
// The potentially malicious string
const untrustedString = "<p>I might be XSS</p><img src='x' onerror='alert(1)'>";
// Create a TrustedHTML instance using the policy
const trustedHTML = policy.createHTML(untrustedString);
// Inject the TrustedHTML (which contains a trusted string)
const element = document.querySelector("#container");
element.innerHTML = trustedHTML;
Warnung:
Obwohl Sie direkt einen String innerHTML
zuweisen können, stellt dies ein Sicherheitsrisiko dar, wenn der einzufügende String potenziell bösartigen Inhalt enthalten könnte.
Sie sollten TrustedHTML
verwenden, um sicherzustellen, dass der Inhalt vor dem Einfügen bereinigt wird, und Sie sollten einen CSP-Header setzen, um Trusted Types durchzusetzen.
Spezifikationen
Specification |
---|
HTML> # dom-element-innerhtml> |
Browser-Kompatibilität
Loading…
Siehe auch
Node.textContent
undHTMLElement.innerText
Element.insertAdjacentHTML()
Element.outerHTML
- Parsen von HTML oder XML in einen DOM-Baum:
DOMParser
- Serialisierung eines DOM-Baums in einen XML-String:
XMLSerializer
Element.getHTML()
ShadowRoot.getHTML()
Element.setHTMLUnsafe()
ShadowRoot.setHTMLUnsafe()
- Trusted Types API