---
title: "Vulnerabilità XSS"
description: "Vulnerabilità XSS: come uno script iniettato viene eseguito nel browser dei visitatori, i tipi memorizzata, riflessa e DOM, e come proteggere WordPress."
language: "it"
locale: "it-IT"
type: "definition"
canonical: "https://www.wp-masquerade.com/it/glossario/vulnerabilita-xss/"
published: "2026-10-28T08:00:00+00:00"
modified: "2026-10-28T20:03:41+00:00"
translations:
  it-IT: "https://www.wp-masquerade.com/it/glossario/vulnerabilita-xss/index.md"
  en-US: "https://www.wp-masquerade.com/glossary/xss/index.md"
  fr-FR: "https://www.wp-masquerade.com/fr/definitions/faille-xss/index.md"
  es-ES: "https://www.wp-masquerade.com/es/glosario/vulnerabilidad-xss/index.md"
  de-DE: "https://www.wp-masquerade.com/de/glossar/cross-site-scripting/index.md"
  pt-BR: "https://www.wp-masquerade.com/pt/glossario/vulnerabilidade-xss/index.md"
  nl-NL: "https://www.wp-masquerade.com/nl/woordenlijst/cross-site-scripting/index.md"
---

# Vulnerabilità XSS

Una vulnerabilità XSS (cross-site scripting) permette a un attaccante di far eseguire il proprio JavaScript nella pagina che un altro visitatore sta consultando. Lo script agisce allora nel browser della vittima con i diritti del sito: azioni a suo nome, lettura dei dati mostrati o reindirizzamento.

La sigla XSS viene dall’inglese cross-site scripting; si scrive X invece di C per evitare la confusione con i fogli di stile CSS. È una vulnerabilità di tipo injection: il sito inserisce nella pagina un dato proveniente dall’esterno senza neutralizzarlo, e il browser lo interpreta come codice. Il MITRE la cataloga con l’identificativo CWE-79. Poiché lo script sembra provenire dal sito stesso, il browser gli concede la stessa fiducia che al resto della pagina.

## Come funziona un attacco XSS

Tutto parte da un valore controllato dall’attaccante: un parametro dell’indirizzo, un campo di un modulo, un commento, un header HTTP registrato nelle statistiche. Se il codice mostra questo valore così com’è, una stringa come `<script>…</script>` o un attributo `onerror="…"` diventa eseguibile. Lo script può allora leggere il contenuto della pagina, inviare richieste a nome della persona connessa, modificare ciò che vede o reindirizzarla verso un altro sito.

![Schema in cinque passaggi di una XSS memorizzata: l’attaccante inietta un tag script in un campo, il sito lo salva, un amministratore apre la schermata interessata, la pagina restituisce lo script senza escaping e lo script agisce nella sessione dell’amministratore](https://www.wp-masquerade.com/media/2026/10/xss-stockee-it.webp)

*Una XSS memorizzata aspetta la sua vittima: basta che un amministratore visualizzi il dato trappola.*

Su un sito WordPress, il bersaglio preferito è l’amministratore. Uno script eseguito nella sua sessione può creare un account, installare un plugin o cambiare un’impostazione, senza mai conoscere la sua password: è il browser stesso a inviare i cookie di login con ogni richiesta.

## I diversi tipi di XSS

- **XSS memorizzata (persistente)**: lo script viene salvato lato server, per esempio nel database, e poi restituito a ogni visualizzazione. Alla vittima non è richiesta alcuna azione particolare, le basta aprire la pagina.
- **XSS riflessa**: lo script viaggia nella richiesta, spesso un link trappola, e il server lo ricopia subito nella risposta. La vittima deve cliccare.
- **XSS basata sul DOM**: è il JavaScript della pagina a inserire un dato non affidabile, come il frammento di un indirizzo. Il server può non vedere passare nulla.

OWASP descrive anche la XSS «cieca» (blind XSS): una variante memorizzata che scatta più tardi, in un’interfaccia che l’attaccante non vede. È proprio il caso di log, statistiche e moduli ricevuti consultati dalla Bacheca. Gli esempi reali di XSS in plugin popolari mostrano che questo scenario non ha nulla di teorico.

*Video (in inglese): «Cross-Site Scripting (XSS) Explained» (PwnFunction)*

## Per WordPress: fare l’escaping all’ultimo momento

La documentazione per sviluppatori di WordPress fissa una regola semplice: fare l’escaping il più tardi possibile, nel momento in cui il dato viene mostrato, con la funzione che corrisponde al contesto.

| Contesto di visualizzazione | Funzione |
| --- | --- |
| Testo dentro un elemento HTML | `esc_html()` |
| Valore di un attributo | `esc_attr()` |
| Indirizzo in href o src | `esc_url()` |
| JavaScript inline | `esc_js()` |
| Contenuto di una textarea | `esc_textarea()` |
| HTML in cui alcuni tag sono ammessi | `wp_kses()`, `wp_kses_post()` |

```
<h2><?php echo esc_html( $titolo ); ?></h2>
<a href="<?php echo esc_url( $link ); ?>" title="<?php echo esc_attr( $info ); ?>">Vedi</a>
```

Validare e sanificare gli input resta utile, ma non sostituisce questo escaping in uscita: uno stesso valore può essere mostrato in più contesti.

## Come proteggersi senza toccare il codice

- Aggiornare in fretta plugin e temi: le XSS sfruttate in massa colpiscono quasi sempre versioni già corrette.
- Tenere pochi account con privilegi ed eliminare quelli che non servono più.
- Sorvegliare la comparsa di nuovi amministratori, segnale frequente di una XSS sfruttata.
- Aggiungere una [Content Security Policy](https://www.wp-masquerade.com/it/glossario/content-security-policy/), sapendo che una versione rigida, che vieta gli script inline, è difficile da mantenere con WordPress. La nostra guida agli [header di sicurezza HTTP per WordPress](https://www.wp-masquerade.com/it/intestazioni-sicurezza-http-wordpress/) descrive le opzioni.
- Un [firewall applicativo](https://www.wp-masquerade.com/it/glossario/waf/) può fermare payload noti, senza garanzie contro una variante inedita.

WP Masquerade Pro invia degli [header di sicurezza](https://www.wp-masquerade.com/it/funzionalita/header-di-sicurezza/), tra cui, come opzione, una CSP di base. Questa CSP non limita gli script: non blocca quindi una XSS. WP Masquerade non è né un firewall applicativo né uno strumento che corregge il codice: solo l’aggiornamento del componente difettoso chiude la vulnerabilità.

## Errori frequenti

- Confondere XSS e [CSRF](https://www.wp-masquerade.com/it/glossario/csrf/): la seconda fa inviare al browser una richiesta contraffatta, senza eseguire script nella pagina. Una XSS, invece, permette di aggirare le protezioni anti-CSRF, perché lo script legge i token della pagina.
- Credere che un dato sia «interno» perché viene mostrato nell’amministrazione: un header HTTP o un indirizzo visitato arrivano dall’esterno.
- Usare `esc_html()` in un attributo o `esc_attr()` per un indirizzo: ogni contesto ha la sua funzione.
- Pensare che la protezione contro la [SQL injection](https://www.wp-masquerade.com/it/glossario/sql-injection/) basti: un dato salvato correttamente nel database può restare pericoloso al momento della visualizzazione.

## Termini correlati

- [CSP (Content Security Policy)](https://www.wp-masquerade.com/it/glossario/content-security-policy/)
- [SQL injection](https://www.wp-masquerade.com/it/glossario/sql-injection/)
- [CSRF (cross-site request forgery)](https://www.wp-masquerade.com/it/glossario/csrf/)
- [Header di sicurezza HTTP](https://www.wp-masquerade.com/it/glossario/header-sicurezza-http/)
- [Nonce](https://www.wp-masquerade.com/it/glossario/nonce/)


## Fonti

- [OWASP : Cross Site Scripting (XSS)](https://owasp.org/www-community/attacks/xss/)
- [MITRE CWE-79 : Improper Neutralization of Input During Web Page Generation (Cross-site Scripting)](https://cwe.mitre.org/data/definitions/79.html)
- [WordPress Developer Resources : Escaping Data](https://developer.wordpress.org/apis/security/escaping/)