Penso che questo meccanismo avrebbe valore reale solo in una serie specifica di circostanze.
Nel caso generale, di una normale applicazione web, sarebbe meglio correggere il codice per essere sicuro con XSS, come scritto da @SteveS.
Tuttavia, ci sono alcuni scenari in cui ciò non è facilmente possibile e questi scenari stanno diventando sempre più popolari. Mi riferisco a "contenuti generati dagli utenti", in cui è necessario consentire agli utenti di inserire (quasi) tutti i dati, compresi contenuti HTML arbitrari - blog, siti di social networking, CMS, ecc ...
Ora, la parte di sicurezza-pro di me si sta facendo piccola, e subito voglio saltare e gridare: "No, non devi avere bisogno di farlo, trovare un modo migliore! ". Ma ovviamente non è proprio questo il punto ...
E sì, ci sono diversi modi per evitare questa situazione, con gli utenti che inseriscono un codice HTML arbitrario - che consente di aggiungere alcuni tag o utilizzare un sistema di markup alternativo (come Markdown usato qui) - ma quelli sono una sorta di kludge, limitando la funzionalità e non banale per alcuni utenti finali.
In conclusione, là sarà alcune webapp che accettano HTML arbitrario , per qualsiasi motivo l'azienda ritenga necessario, e può essere controproducente parlare di come è insicuro, perché non funzionerà.
In questi casi, la politica di sicurezza dei contenuti può aggiungere un grande valore e mitigare la funzionalità XSS in larga misura.