Perché esistono i character reference
HTML usa alcuni caratteri come parte della sintassi del markup. I character reference permettono di rappresentare caratteri quando la forma letterale sarebbe ambigua, scomoda o non disponibile, usando nomi come & oppure riferimenti numerici.
Non ogni carattere deve essere trasformato in entity. HTML moderno gestisce Unicode direttamente; le entity sono soprattutto necessarie per caratteri con ruolo sintattico o per rappresentazioni convenzionali.
Named e numeric references
Le named character references associano nomi definiti dallo standard a caratteri o sequenze; i riferimenti numerici usano il code point in decimale o esadecimale. Entrambe le forme vengono risolte dal parser HTML nel testo risultante.
Il riferimento numerico riguarda un code point Unicode, non i byte UTF-8 con cui il documento viene trasmesso. Encoding del file e sintassi delle entity sono livelli distinti.
Escaping dipende dal contesto
Testo HTML, valori di attributo, URL, CSS e JavaScript embedded hanno grammatiche diverse. L'escaping corretto deve conoscere il contesto di output: una sostituzione adatta a un text node può essere insufficiente o sbagliata dentro uno script.
Per questo i template engine sicuri applicano escaping contestuale. Disattivare l'auto-escaping o concatenare manualmente markup con input non fidato aumenta il rischio di interpretazione come codice.
Escaping e sanitization
Escaping tratta dati come testo all'interno di un contesto specifico. Sanitization, invece, riceve markup potenzialmente attivo e rimuove o limita elementi, attributi e URL secondo una policy.
Se un'applicazione vuole consentire un sottoinsieme di HTML prodotto dagli utenti, non basta sostituire < e >. Serve un sanitizer HTML robusto e aggiornato che lavori sulla struttura analizzata.
XSS e confini di fiducia
Cross-site scripting nasce quando dati controllabili da un attaccante raggiungono un contesto eseguibile nel browser. La prevenzione richiede output encoding contestuale, sanitization quando si accetta HTML e API che evitino sink pericolosi.
Le entity non sono un filtro di sicurezza universale: un valore può essere sicuro come testo e pericoloso se successivamente decodificato o inserito in un altro contesto. Segui l'intero percorso dei dati.
Best practice
Mantieni UTF-8 end-to-end, lascia l'escaping al framework quando possibile e non eseguire decode/encode ripetuti senza un contratto chiaro. Testa caratteri speciali, virgolette, ampersand e input Unicode ai confini.
Quando il requisito è mostrare testo, usa primitive che producono text node. Quando devi accettare markup, definisci una allowlist e usa librerie di sanitization mature invece di espressioni regolari o sostituzioni ad hoc.
