Cross-site scripting (XSS): co to jest i jak działa?

Cross-Site Scripting (XSS) to podatność bezpieczeństwa aplikacji webowych, która pozwala atakującemu na wstrzyknięcie złośliwego kodu JavaScript do treści wyświetlanej innym użytkownikom. XSS umożliwia m.in. kradzież ciasteczek sesyjnych, przejęcie konta, manipulację interfejsem lub wykonanie działań w imieniu ofiary. Występuje, gdy aplikacja nieprawidłowo filtruje lub nie koduje danych wejściowych przed ich wyświetleniem w przeglądarce.

Aby zabezpieczyć aplikację, warto zastosować trzy kluczowe metody: walidację danych wejściowych, kodowanie danych wyjściowych oraz wdrożenie Content Security Policy (CSP). Te kroki minimalizują ryzyko ataku i chronią wrażliwe dane użytkowników.

❌ Poniższe informacje podane są jedynie w celach edukacyjnych.

Czym jest Cross-site scripting (XSS)?

Polityka samego źródła (Same-Origin Policy) jest kluczowa dla bezpieczeństwa przeglądarek. Zasada ta ogranicza dostęp skryptów do danych pochodzących z innej domeny. XSS omija tę ochronę, oszukując przeglądarkę, że złośliwy skrypt pochodzi z zaufanej strony.

Atak ten polega na wprowadzeniu szkodliwego kodu przez niezaufane źródła, takie jak formularze czy parametry URL. Na przykład, jeśli użytkownik wypełni formularz kontaktowy, a dane nie zostaną zweryfikowane, atakujący może wstrzyknąć skrypt, który zostanie wykonany w przeglądarce ofiary.

Przykładem może być atak na bankowość online. Jeśli strona banku nie zabezpieczy danych wejściowych, atakujący może przekierować użytkownika na fałszywą stronę, podszywającą się pod bank. W ten sposób złośliwy skrypt może przechwycić dane logowania.

Różnica między aktywnym a pasywnym XSS polega na sposobie wykonania kodu. W przypadku ataku aktywnego, skrypt jest natychmiast wykonywany, podczas gdy wersja pasywna przechowuje go w bazie danych, aby zaatakować kolejnych użytkowników.

Same-Origin Policy	XSS
Ogranicza dostęp skryptów do danych z innych domen.	Omija tę ochronę, wprowadzając złośliwy kod.
Zapewnia bezpieczeństwo przeglądarek.	Wykorzystuje luki w modelu bezpieczeństwa.
Chroni dane użytkownika.	Przechwytuje dane użytkownika.

Mechanizm propagacji złośliwego skryptu między użytkownikami jest prosty. Jeśli strona nie zabezpieczy danych wyjściowych, skrypt może być przekazywany dalej, infekując kolejne przeglądarki. Dlatego tak ważne jest stosowanie walidacji danych i kodowania wyjściowego.

Jak działa atak Cross-site scripting (XSS)?

Mechanizm ataku XSS opiera się na wprowadzeniu złośliwego kodu do przeglądarki użytkownika. Proces ten można podzielić na trzy główne fazy: iniekcję, przechowywanie i wykonanie.

W fazie iniekcji atakujący wprowadza szkodliwy skrypt do aplikacji, często poprzez niezakodowane parametry URL lub formularze. Następnie, skrypt jest przechowywany w systemie, np. w bazie danych, aby mógł zostać wykonany w przeglądarce ofiary.

Przykładem może być atak wykorzystujący niezakodowane parametry wyszukiwania. Jeśli aplikacja nie zabezpieczy danych wyjściowych, atakujący może wstrzyknąć skrypt, który zostanie wyświetlony na stronie wyników.

Schemat komunikacji w ataku XSS wygląda następująco:

• Ofiara odwiedza zarażoną stronę.
• Złośliwy skrypt jest przekazywany do przeglądarki ofiary.
• Skrypt komunikuje się z serwerem atakującego, przesyłając wrażliwe dane.

Atakujący może dostarczyć payload na różne sposoby, np. poprzez wiadomości phishingowe, zarażone reklamy lub kompromitowane CDN. Techniki te często wykorzystują zdarzenia onerror lub onload w tagach HTML, aby wymusić wykonanie skryptu.

Przykładowy kod wykorzystujący zdarzenie onerror: <img src=x onerror=alert(‘XSS’)>. Ten skrypt wywoła alert w przeglądarce, jeśli obraz nie zostanie załadowany.

Zrozumienie mechanizmu ataku XSS jest kluczowe dla skutecznej ochrony aplikacji webowych. W kolejnych sekcjach omówimy rodzaje ataków oraz metody ich wykrywania i zapobiegania.

Jakie są rodzaje ataków Cross-site scripting (XSS)?

Ataki XSS można podzielić na kilka typów, z których każdy ma unikalne cechy i mechanizmy działania. Wyróżniamy cztery główne rodzaje: Reflected, Stored, DOM-based oraz Blind. Każdy z nich wymaga innego podejścia do wykrywania i zapobiegania.

• Reflected XSS występuje, gdy złośliwy skrypt jest przekazywany przez parametry URL lub formularze, a następnie odbijany przez serwer. Przykładem może być błąd 404, który nie filtruje danych wejściowych, co pozwala na wykonanie skryptu w przeglądarce ofiary.
• Stored XSS polega na trwałym przechowywaniu złośliwego kodu w bazie danych aplikacji. Przykładem jest system komentarzy, gdzie niezabezpieczone dane mogą być wykorzystane do infekowania kolejnych użytkowników.
• DOM-based XSS wykorzystuje manipulację Document Object Model (DOM) przeglądarki. Atakujący modyfikuje URL, aby wstrzyknąć skrypt, który zostanie wykonany po załadowaniu strony. Ten typ ataku jest szczególnie niebezpieczny w aplikacjach SPA, takich jak React czy Angular.
• Blind XSS to zaawansowana forma ataku, gdzie złośliwy skrypt jest przechowywany w systemie i wykonywany w późniejszym czasie. Narzędzia takie jak XSS Hunter pomagają w identyfikacji tego typu luk.

Typ ataku	Mechanizm	Przykład
Reflected	Odbijanie skryptu przez serwer	Błąd 404
Stored	Przechowywanie skryptu w bazie danych	System komentarzy
DOM-based	Manipulacja DOM przeglądarki	Modifikacja URL
Blind	Wykonanie skryptu w późniejszym czasie	XSS Hunter

Według raportów OWASP z 2023 roku, najczęściej występującym typem jest Reflected XSS, ale Stored i DOM-based również stanowią poważne zagrożenie. W aplikacjach SPA, takich jak React, podatności na DOM-based XSS są szczególnie częste ze względu na dynamiczne renderowanie treści.

Analiza podatności w tradycyjnych aplikacjach (np. Express) vs SPA (np. React) pokazuje, że każda z nich wymaga innego podejścia do zabezpieczeń. W tradycyjnych aplikacjach kluczowa jest walidacja danych wejściowych, podczas gdy w SPA ważne jest zabezpieczenie przed manipulacją DOM.

Narzędzia takie jak XSS Hunter są niezbędne do identyfikacji Blind XSS, ponieważ ten typ ataku jest trudny do wykrycia bez specjalistycznych rozwiązań. Regularne testy penetracyjne i audyty bezpieczeństwa pomagają w minimalizacji ryzyka.

Jakie są konsekwencje ataku Cross-site scripting (XSS)?

Ataki XSS mogą prowadzić do poważnych konsekwencji, zarówno finansowych, jak i prawnych. Według raportu IBM z 2024 roku, średni koszt incydentu związanego z wyciekiem danych wynosi $4.9 mln. W przypadku naruszenia RODO, kary mogą sięgać nawet 20 mln EUR.

Przykładem może być atak na stronę apteki, gdzie modyfikacja dawek leków mogła narazić życie pacjentów. Takie incydenty nie tylko narażają wrażliwe dane, ale także prowadzą do utraty zaufania klientów.

W branży e-commerce atak XSS może przekierować klientów na phishingowy payment gateway. To nie tylko prowadzi do utraty danych finansowych, ale także niszczy reputację sklepu. W przypadku ujawnienia danych medycznych, firmy mogą stanąć przed problemami prawnymi zgodnie z HIPAA.

Scenariusz ataku na infrastrukturę IoT poprzez panel administracyjny pokazuje, jak szerokie mogą być konsekwencje. Złośliwy skrypt może przejąć kontrolę nad urządzeniami, co prowadzi do defacement lub nawet awarii systemów.

Konsekwencja	Przykład
Finansowe	Kary do 20 mln EUR w RODO
Reputacyjne	Utrata zaufania klientów w e-commerce
Prawne	Problemy zgodnie z HIPAA
Techniczne	Defacement infrastruktury IoT

Zrozumienie konsekwencji ataków XSS jest kluczowe dla skutecznej ochrony. Wdrożenie odpowiednich zabezpieczeń minimalizuje ryzyko i chroni zarówno dane, jak i reputację firmy.

Jak wykryć luki Cross-site scripting (XSS) w aplikacji?

Identyfikacja luk w aplikacjach wymaga precyzyjnych metod i narzędzi. Proces ten można podzielić na pięć kluczowych etapów: mapowanie inputów, fuzzing, analiza odpowiedzi, code review oraz analiza pokrycia testowego. Każdy z tych kroków jest niezbędny do skutecznego wykrywania podatności.

Pierwszym etapem jest mapowanie wszystkich punktów wejścia danych w aplikacji. To pozwala zidentyfikować miejsca, gdzie mogą wystąpić luki. Następnie, fuzzing pomaga przetestować różne kombinacje danych wejściowych, aby wykryć potencjalne błędy.

Analiza odpowiedzi obejmuje sprawdzenie, czy aplikacja prawidłowo filtruje i koduje dane wyjściowe. Code review to manualne przeglądanie kodu w poszukiwaniu niebezpiecznych metod, takich jak eval() czy innerHTML. Ostatnim etapem jest analiza pokrycia testowego z użyciem narzędzi DAST/SAST.

Porównanie skuteczności narzędzi open-source i komercyjnych pokazuje, że OWASP ZAP i Acunetix są równie efektywne w wykrywaniu luk. Jednak Acunetix oferuje bardziej zaawansowane funkcje, takie jak automatyczne skanowanie i raportowanie.

Narzędzie	Zalety	Wady
OWASP ZAP	Bezpłatne, elastyczne, wsparcie społeczności	Wymaga większej ręcznej konfiguracji
Acunetix	Automatyczne skanowanie, szczegółowe raporty	Wysoki koszt licencji

Metodyka code review obejmuje identyfikację niezakodowanych outputów w templatach. Użycie regex do wykrywania niebezpiecznych metod, takich jak eval(), jest kluczowe dla minimalizacji ryzyka. Przykładowo, skrypt <svg onload=alert(1)> może być użyty do testowania podatności.

Analiza pokrycia testowego z narzędziami DAST/SAST pozwala ocenić, czy wszystkie części aplikacji zostały przetestowane. Kombinacja skanowania automatycznego i manualnego przeglądu kodu, zgodnie z zaleceniami OWASP, jest najskuteczniejszym podejściem.

Jak zabezpieczyć aplikację przed Cross-site scripting (XSS)?

Skuteczne zabezpieczenie aplikacji przed atakami wymaga kompleksowego podejścia. Kluczowe kroki obejmują walidację danych wejściowych, kodowanie danych wyjściowych oraz wdrożenie odpowiednich polityk bezpieczeństwa.

Walidacja danych wejściowych to pierwszy krok. W PHP można użyć funkcji filter_var, aby oczyścić dane:

$email = filter_var($_POST[’email’], FILTER_SANITIZE_EMAIL);

W Java zaleca się korzystanie z biblioteki OWASP ESAPI:

String safeInput = ESAPI.encoder().encodeForHTML(userInput);

Kodowanie danych wyjściowych jest równie ważne. HTML Entity Encoding zamienia znaki specjalne na encje, np. < na <. URL Encoding konwertuje znaki na format bezpieczny dla adresów URL.

W przypadku aplikacji React, implementacja Content Security Policy (CSP) z użyciem nonce jest skutecznym rozwiązaniem. Przykład konfiguracji:

Content-Security-Policy: script-src ‘nonce-abc123’;

Frameworki bezpieczeństwa, takie jak Django i React, oferują wbudowane mechanizmy ochrony. Django automatycznie escapuje dane w szablonach, a React JSX domyślnie koduje wartości.

Nagłówki HTTP, takie jak X-XSS-Protection i X-Content-Type-Options, również zwiększają bezpieczeństwo. Pierwszy blokuje wykryte ataki, a drugi zapobiega MIME-sniffingowi.

• Walidacja danych wejściowych: Oczyszczanie danych przed przetworzeniem.
• Kodowanie danych wyjściowych: Bezpieczne wyświetlanie danych.
• Content Security Policy: Ograniczenie wykonywania skryptów.
• Frameworki bezpieczeństwa: Gotowe rozwiązania ochronne.

Zastosowanie tych metod minimalizuje ryzyko ataków i chroni wrażliwe dane użytkowników. Regularne audyty i testy penetracyjne są niezbędne do utrzymania wysokiego poziomu bezpieczeństwa.

Jak ochronić się przed atakiem Cross-site scripting?

Skuteczne zabezpieczenie aplikacji przed atakami Cross-site scripting (XSS) wymaga nie tylko technologii, ale także odpowiednich procesów. Wdrożenie najlepszych praktyk, takich jak aktualizacje oprogramowania, security headers oraz szkolenia developerów, to klucz do minimalizacji ryzyka.

Jednym z najważniejszych kroków jest integracja bezpieczeństwa w cyklu życia rozwoju oprogramowania (SDLC). Dzięki temu każda faza projektu uwzględnia aspekty ochrony danych. Regularne audyty i testy penetracyjne pozwalają na szybkie wykrycie i naprawę luk.

Wzorcowa konfiguracja nagłówków bezpieczeństwa dla serwerów Nginx lub Apache to kolejny istotny element. Przykładowo, nagłówek Content-Security-Policy ogranicza wykonywanie niebezpiecznych skryptów, a X-XSS-Protection blokuje wykryte ataki.

Programy bug bounty, takie jak HackerOne, są skutecznym sposobem na identyfikację podatności. Firmy oferują nagrody za zgłoszenie luk, co zachęca specjalistów do współpracy. Case study pokazują, że takie inicjatywy mogą znacząco poprawić bezpieczeństwo aplikacji.

Implementacja automatycznych skanów w procesie CI/CD, np. z użyciem GitLab SAST, pozwala na szybkie wykrywanie błędów. Metryki skuteczności, takie jak czas reakcji na incydenty czy pokrycie testami, pomagają ocenić efektywność wdrożonych rozwiązań.

Threat modeling to kolejna kluczowa praktyka. Analiza potencjalnych zagrożeń na wczesnym etapie projektu pozwala na lepsze przygotowanie się do ich neutralizacji. Monitoring incydentów z kolei umożliwia szybką reakcję na wykryte ataki.

Przykładowa polityka CSP może wyglądać następująco:

Content-Security-Policy: default-src ‘self’; script-src ‘nonce-abc123’;

Te kroki, połączone z regularnymi szkoleniami i aktualizacjami, tworzą kompleksową strategię ochrony przed zagrożeniami. Wdrożenie tych praktyk nie tylko zwiększa bezpieczeństwo, ale także buduje zaufanie użytkowników.

Przykłady ataków Cross-site scripting (XSS)

Historie ataków XSS pokazują, jak łatwo można wykorzystać luki w zabezpieczeniach. Oto kilka znanych przypadków ataków typu Cross-Site Scripting (XSS) na renomowane firmy, wraz ze szczegółami dotyczącymi wykorzystanych luk i skutków tych incydentów:

Atak XSS na Google – Luka w DoubleClick (2017)

W 2017 roku Google ostrzegł użytkowników platformy DoubleClick o potencjalnej luce XSS związanej z projektowaniem reklam. Błąd ten mógł umożliwić atakującym wstrzyknięcie złośliwego kodu JavaScript poprzez reklamy, co mogło prowadzić do przejęcia sesji użytkownika lub innych niepożądanych działań. Google zalecił reklamodawcom dokładne sprawdzanie kodu reklamowego i unikanie niebezpiecznych praktyk .

Te przykłady pokazują, jak ważne jest zabezpieczenie aplikacji przed atakami. Developerzy powinni zwracać szczególną uwagę na walidację danych i kodowanie wyjściowe, aby uniknąć podobnych incydentów.

Atak XSS na Facebook – Luka w narzędziu tłumaczeń (marzec 2011)

W marcu 2011 roku odkryto lukę typu reflected XSS w narzędziu tłumaczeń Facebooka. Funkcja wyszukiwania w tym narzędziu nieprawidłowo przetwarzała dane wejściowe użytkownika, co pozwalało na wstrzyknięcie złośliwego kodu JavaScript. Choć luka ta znajdowała się w mniej używanej części serwisu, mogła być wykorzystana do przejęcia sesji użytkownika lub kradzieży danych. Facebook szybko załatał lukę po jej zgłoszeniu przez badacza bezpieczeństwa.

Atak XSS na Twitter – „onMouseOver” (wrzesień 2010)

We wrześniu 2010 roku Twitter padł ofiarą ataku XSS, który wykorzystał funkcję onmouseover w JavaScript.Wystarczyło, aby użytkownik najechał kursorem na złośliwy link w tweecie, co powodowało automatyczne wykonanie kodu JavaScript. Ten kod mógł m.in. automatycznie retweetować złośliwe wiadomości z konta ofiary. Atak rozprzestrzeniał się wirusowo i dotknął dziesiątki tysięcy użytkowników, w tym znane osoby publiczne. Twitter szybko załatał lukę, jednak incydent ten uwidocznił poważne konsekwencje zaniedbań w zakresie bezpieczeństwa aplikacji webowych.

Atak XSS na Fortnite (2019)

W 2019 roku odkryto lukę XSS w nieużywanej już stronie internetowej powiązanej z grą Fortnite. Ta luka umożliwiała atakującym przejęcie sesji użytkowników, co potencjalnie pozwalało na dostęp do danych osobowych, podsłuchiwanie rozmów oraz kradzież wirtualnej waluty w grze. Szacuje się, że zagrożonych było ponad 200 milionów kont graczy.

Atak XSS na British Airways (2018)

W 2018 roku grupa hakerska Magecart przeprowadziła atak na British Airways, wykorzystując lukę XSS w zewnętrznej bibliotece JavaScript (Feedify) osadzonej na stronie linii lotniczych. Złośliwy skrypt został wstrzyknięty do strony z informacjami o bagażu, co pozwoliło na przechwytywanie danych klientów, takich jak imiona, adresy e-mail, numery kart płatniczych, daty ważności i kody CVV. Atak objął również aplikację mobilną British Airways, ponieważ korzystała ona z tego samego komponentu JavaScript. W wyniku tego incydentu dane z około 380 000 transakcji zostały skradzione.

Jakie są narzędzia do walki z atakami Cross-site scripting (XSS)?

W walce z zagrożeniami bezpieczeństwa aplikacji webowych kluczową rolę odgrywają specjalistyczne narzędzia. Dzięki nim możliwe jest skuteczne wykrywanie i neutralizowanie luk, które mogą zostać wykorzystane przez atakujących. Poniżej przedstawiamy przegląd najważniejszych rozwiązań.

Jednym z najbardziej znanych narzędzi jest Burp Suite. To kompleksowe rozwiązanie do testów penetracyjnych, które pozwala na manualne i automatyczne skanowanie aplikacji. Dzięki funkcjom takim jak intercepting proxy, skaner luk czy narzędzie do brute force, Burp Suite jest niezastąpiony w rękach specjalistów.

Kolejnym wartym uwagi narzędziem jest OWASP ZAP. To darmowy skaner open-source, który oferuje szeroki zakres funkcji, od automatycznego skanowania po zaawansowane testy manualne. Jego integracja z Jenkinsem w procesie CI/CD pozwala na ciągłe monitorowanie bezpieczeństwa aplikacji.

Do wykrywania Blind XSS szczególnie przydatny jest XSS Hunter. To narzędzie pozwala na przechwytywanie złośliwych skryptów, które są wykonywane w późniejszym czasie. Dzięki niemu możliwe jest identyfikowanie luk, które są trudne do wykrycia tradycyjnymi metodami.

W przypadku aplikacji SPA, takich jak React czy Angular, warto rozważyć użycie Acunetix. To komercyjny skaner, który oferuje zaawansowane funkcje, w tym konfigurację zasad skanowania dostosowanych do dynamicznych aplikacji.

Narzędzie	Zalety	Wady
Burp Suite	Kompleksowe funkcje, wsparcie dla testów manualnych	Wysoki koszt licencji
OWASP ZAP	Bezpłatne, elastyczne, wsparcie społeczności	Wymaga większej ręcznej konfiguracji
XSS Hunter	Skuteczne w wykrywaniu Blind XSS	Ograniczone do konkretnego typu ataku
Acunetix	Zaawansowane skanowanie, szczegółowe raporty	Wysoki koszt licencji

Według rekomendacji OWASP, najlepszym podejściem jest kombinacja narzędzi do testów manualnych, takich jak Burp Suite Pro, oraz automatyzacji z użyciem OWASP ZAP. Dzięki temu możliwe jest kompleksowe zabezpieczenie aplikacji na każdym etapie rozwoju.

Analiza kosztów pokazuje, że narzędzia open-source, takie jak OWASP ZAP, są równie skuteczne jak rozwiązania komercyjne, ale wymagają większego zaangażowania ze strony zespołu. Z kolei narzędzia enterprise, takie jak Checkmarx czy Veracode, oferują zaawansowane funkcje, ale ich cena może być barierą dla mniejszych firm.

Wdrożenie odpowiednich narzędzi do walki z zagrożeniami jest kluczowe dla zapewnienia bezpieczeństwa aplikacji. Regularne testy i audyty pozwalają na szybkie wykrycie i naprawę luk, minimalizując ryzyko ataków.

Podsumowanie

W kontekście rosnących zagrożeń cybernetycznych, kluczowe jest budowanie skutecznych strategii ochrony. Według raportu Verizon 2023, aż 23% incydentów w aplikacjach webowych wynika z luk w zabezpieczeniach. Dlatego ciągłe doskonalenie procesów bezpieczeństwa staje się priorytetem.

Prognozy na 2025 rok wskazują na wzrost ataków w aplikacjach IoT i IIoT. To wymaga zwiększenia inwestycji w prewencję, a nie tylko reakcję na incydenty. Budżet na cyberbezpieczeństwo powinien uwzględniać zarówno narzędzia, jak i szkolenia dla zespołów.

Budowa kultury bezpieczeństwa w organizacji to kolejny kluczowy krok. Świadomość zagrożeń wśród pracowników oraz wdrożenie przynajmniej trzech warstw zabezpieczeń minimalizuje ryzyko ataków. Działaj już dziś, aby zabezpieczyć swoją firmę przed przyszłymi wyzwaniami.

Ochrona przed atakami Cross-site scripting (XSS) z Pentestica

W Pentestica zapewniamy skuteczną ochronę przed atakami typu Cross Site Scripting (XSS), wdrażając nowoczesne i kompleksowe rozwiązania bezpieczeństwa. Korzystamy z systemów IDS/IPS, które nieustannie monitorują ruch sieciowy i automatycznie blokują złośliwe działania — zanim zdążą zagrozić Twojej infrastrukturze.

W ramach ochrony aplikacji webowych oferujemy także zapory WAF (Web Application Firewall), wyposażone w zaawansowane reguły wykrywające zarówno klasyczne, jak i zaciemnione formy ataków XSS w żądaniach HTTP. Nasze rozwiązania są skuteczne już przy domyślnych ustawieniach – nie wymagają dodatkowych zmian w kodzie aplikacji.

Zadbaj o bezpieczeństwo swoich użytkowników i aplikacji internetowych z pomocą ekspertów Pentestica. Skontaktuj się z nami – pokażemy Ci, jak skutecznie eliminować ryzyko XSS.

Bibliografia

1. Wikipedia contributors (2025). “Cross-site scripting”. Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/wiki/Cross-site_scripting

2. Wikipedia contributors (2025). “Self-XSS”. Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/wiki/Self-XSS

3. Wikipedia contributors (2025). “XSS worm”. Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/wiki/XSS_worm

4. Wikipedia contributors (2025). “Content Security Policy”. Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/wiki/Content_Security_Policy

5. Hannousse, A., Yahiouche, S., & Nait-Hamoud, M. C. (2022). “Twenty-two years since revealing cross-site scripting attacks: a systematic mapping and a comprehensive survey”. arXiv preprint arXiv:2205.08425. https://arxiv.org/abs/2205.08425

6. Mohammadi, M., Chu, B.-T., & Lipford, H. R. (2018). “Automated Detecting and Repair of Cross-Site Scripting Vulnerabilities”. arXiv preprint arXiv:1804.01862. https://arxiv.org/abs/1804.01862

7. Wijayarathna, C., & Arachchilage, N. A. G. (2018). “Fighting Against XSS Attacks: A Usability Evaluation of OWASP ESAPI Output Encoding”. arXiv preprint arXiv:1810.01017. https://arxiv.org/abs/1810.01017

8. Kshetri, N., Kumar, D., Hutson, J., Kaur, N., & Osama, O. F. (2024). “algoXSSF: Detection and analysis of cross-site request forgery (XSRF) and cross-site scripting (XSS) attacks via Machine learning algorithms”. arXiv preprint arXiv:2402.01012. https://arxiv.org/abs/2402.01012

9. Garcia-Alfaro, J., & Navarro-Arribas, G. (2009). “A Survey on Cross-Site Scripting Attacks”. arXiv preprint arXiv:0905.4850. https://arxiv.org/abs/0905.4850

10. Wikipedia contributors (2025). “HTML sanitization”. Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/wiki/HTML_sanitization