XSS przez innerHTML i zapobieganie atakom

Przypisanie el.innerHTML = userInput analizuje ciąg znaków jako kod HTML. Jeśli userInput zawiera znaczniki <script> lub atrybuty obsługi zdarzeń (onclick, onerror), przeglądarka je interpretuje i wykonuje kod kontrolowany przez osobę atakującą na stronie.

Każdy kod, który wstawia dane użytkownika do kodu HTML — szablony serwerowe lub renderowanie po stronie klienta — stwarza ryzyko XSS, jeśli dane nie zostały zabezpieczone przez escapowanie. Aplikacje jednostronicowe budujące innerHTML na podstawie odpowiedzi API są szczególnie narażone, gdy odpowiedzi zawierają treści użytkowników.

Nazwa użytkownika "Bob<img src=x onerror=alert(1)>" ustawiona za pomocą div.innerHTML = `Welcome, ${user}` wywołuje alert(1), gdy obraz img nie może się załadować. Ten sam ładunek jako zwykły tekst (przez textContent) jest nieszkodliwy — przeglądarka widzi tylko znaki, a nie znaczniki.

textContent ustawia wyłącznie tekst — specjalne znaki HTML są wyświetlane jako dosłowne znaki, nigdy jako znaczniki. W 90% przypadków jest to właściwe narzędzie. Po innerHTML należy sięgać tylko wtedy, gdy rzeczywiście trzeba wyrenderować kod HTML, a nie zwykły tekst.

Aby utworzyć elementy zawierające dane użytkownika, należy zbudować je za pomocą createElement i textContent: const li = document.createElement("li"); li.textContent = name; ul.appendChild(li);. Wynik ma taką samą strukturę jak w przypadku innerHTML, ale z założenia jest bezpieczny względem XSS.

W przypadku zaufanego kodu HTML wygenerowanego przez serwer (własnego wyniku szablonu lub oczyszczonego tekstu sformatowanego z zaufanego edytora) innerHTML jest odpowiednie. Nigdy nie należy stosować go bezpośrednio do danych z niezaufanych źródeł bez ich oczyszczenia.

Jeśli użytkownicy przesyłają tekst sformatowany (na przykład w edytorze komentarzy lub podczas renderowania Markdown), przed ustawieniem innerHTML należy go oczyścić: el.innerHTML = DOMPurify.sanitize(richHtml). DOMPurify usuwa niebezpieczne znaczniki i atrybuty, zachowując bezpieczne formatowanie, takie jak <b>, <em> i <a>.

el.insertAdjacentHTML("beforeend", html) analizuje ciągi HTML — stwarza takie samo zagrożenie XSS jak innerHTML. Obowiązują te same zasady: nigdy nie należy przekazywać bezpośrednio danych użytkownika; trzeba je oczyścić albo użyć metod DOM. To samo dotyczy document.write, choć obecnie nikt nie powinien już tego używać.

React, Vue, Svelte i Angular domyślnie wykonują escapowanie interpolowanego tekstu — {name} jest bezpieczne. Udostępniają mechanizmy omijające te zabezpieczenia (dangerouslySetInnerHTML w React i v-html w Vue), które niosą takie samo ryzyko XSS; należy używać ich oszczędnie i po oczyszczeniu danych.

Nawet wartości atrybutów mogą być wektorem ataku: <a href={url}> z url="javascript:alert(1)" wykonuje kod po kliknięciu. Przed umieszczeniem danych użytkownika w href, src lub innych atrybutach zawierających adresy URL należy sprawdzać schematy adresów i zezwalać wyłącznie na http:, https:, mailto: oraz tel:.

Współczesne przeglądarki obsługują Trusted Types: należy skonfigurować CSP za pomocą require-trusted-types-for 'script', aby innerHTML odrzucało surowe ciągi znaków — przepuszczane są wyłącznie wartości opakowane przez politykę. Dzięki temu XSS staje się niemożliwe na poziomie API, a nie dzięki samej dyscyplinie programistycznej.

Żadna pojedyncza warstwa nie wystarczy. Należy połączyć walidację danych wejściowych na serwerze, escapowanie danych wyjściowych podczas renderowania, CSP do blokowania wstrzykniętych skryptów, Trusted Types do odrzucania surowych ciągów znaków oraz przegląd bezpieczeństwa każdego użycia innerHTML. Obrona warstwowa pozwala przetrwać błąd w dowolnej pojedynczej warstwie.

Dlaczego el.textContent = userInput jest bezpieczne pod względem XSS, a el.innerHTML = userInput jest niebezpieczne?

Użycie innerHTML z danymi od użytkownika to klasyczny wektor XSS. Do tekstu używaj textContent, do struktury — createElement+textContent, a gdy wymagany jest sformatowany HTML — DOMPurify. Sprawdzaj schematy adresów URL w wartościach atrybutów. Dodaj CSP i Trusted Types, aby neutralizować błędy, które umknęły podczas przeglądu kodu. Nowoczesne frameworki domyślnie wykonują escapowanie — ich niebezpieczne mechanizmy omijające te zabezpieczenia powinny być używane rzadko i poddawane przeglądowi.