En resum
Què es mesura
tres senyals de risc, no una vulnerabilitat confirmada.
Quins
si la política de seguretat de contingut protegeix davant dels scripts, si hi ha paràmetres de l’URL reflectits a l’HTML i si es fan servir funcions perilloses del navegador.
Per què importa
l’XSS és la CWE-79, dins de la categoria d’injecció que OWASP situa al tercer lloc del seu Top 10 del 2021.
Severitat a Wakaris
Important. Salta al 1,5 % de les pàgines analitzades, segons el catàleg de Wakaris mateix.
Què és i què mesura aquesta troballa
La documentació de MDN defineix l’XSS —cross-site scripting— com un atac en què un atacant aconsegueix que el lloc objectiu executi codi maliciós com si formés part del lloc mateix. Hi ha tres variants: la reflectida, en què la dada arriba a l’URL i la pàgina la retorna dins del seu HTML; l’emmagatzemada, en què la dada queda desada —un comentari, per exemple— i se serveix a tothom qui hi entri; i la basada en el DOM, pròpia de pàgines que munten el contingut al navegador.
Convé ser exacte amb el que aquesta troballa diu i el que no. No és un atac de prova ni una confirmació: és un recompte de tres condicions que fan l’atac més fàcil. Pots tenir-les totes tres i no ser vulnerable, si el codi escapa correctament tot el que rep; i pots no tenir-ne cap i ser-ho per una via que no es veu des de l’HTML servit. És una mesura d’exposició, i així s’ha de llegir.
Com es mesura
Wakaris analitza l’URL que li indiquis i retorna els tres senyals per separat, amb el recompte de cadascun: quants paràmetres de l’adreça apareixen reflectits a l’HTML, quants usos de funcions perilloses del navegador troba i si la política de seguretat de contingut protegeix davant de l’execució de scripts. Veure’ls separats és el que permet decidir per on començar.
Hi ha dos límits que aquest article declara en lloc d’amagar. El primer és de mètode: la troballa s’obté llegint la pàgina, no atacant-la, així que mesura indicis i no explotabilitat. El segon és de documentació: el catàleg de Wakaris no diu quines funcions concretes compta com a perilloses ni amb quin criteri considera que una política protegeix, i fa servir un únic tall —més de zero— per als tres senyals, sense trams. Un paràmetre reflectit i vint produeixen la mateixa troballa amb la mateixa severitat.
Per què importa
La conseqüència és que el codi d’un altre s’executa amb els permisos de la teva pàgina: pot llegir el que la persona escriu, actuar en nom seu dins de la seva sessió o canviar el que veu. I la variant emmagatzemada és la pitjor, perquè MDN assenyala que és especialment greu, ja que el contingut infectat se serveix a tots els usuaris que accedeixen a la pàgina, cada vegada que hi accedeixen.
Sobre la freqüència hi ha una dada de font, tot i que convé llegir-la amb cura: OWASP classifica l’XSS com a CWE-79 dins de la categoria d’injecció, que al seu Top 10 del 2021 ocupa el tercer lloc, amb 33 CWE agrupades, 274.228 ocurrències registrades i una taxa d’incidència mitjana del 3,37 % davant d’una màxima del 19,09 %. Aquestes xifres són de la categoria sencera, no d’aquesta troballa, així que no es poden presentar com la taxa de l’XSS. El que sí que diuen és que el 94 % de les aplicacions de l’estudi es van provar contra alguna forma d’injecció: és un problema que es busca a tot arreu.
Causes habituals
La primera i més freqüent és retornar a l’HTML una dada que ha arribat de fora sense transformar-la. L’exemple que fa servir MDN és una pàgina que espera el nom de l’usuari en un paràmetre de l’URL, l’extreu i el fa servir per construir una salutació personalitzada: si ningú no escapa aquest valor, per aquí hi entra codi.
La segona són les funcions del navegador que interpreten el que reben. MDN les agrupa en dues famílies: les que tracten el seu argument com a HTML —innerHTML, outerHTML, insertAdjacentHTML() i document.write()— i les que l’executen com a JavaScript, entre les quals eval(), setTimeout() i setInterval(). Passar-los alguna cosa que no controles del tot és el camí curt cap al problema.
La tercera és una política de seguretat de contingut que no protegeix. MDN avisa que els desenvolupadors haurien d’evitar 'unsafe-inline', perquè destrueix bona part del propòsit de tenir una política; els orígens amb comodí tenen el mateix efecte per una altra via. I la quarta, més silenciosa: fer servir un sistema de plantilles que escapa automàticament i saltar-se’l just al lloc on entra la dada de fora.
Com solucionar-ho
Wakaris et diu quin dels tres senyals apareix, i d’això depèn l’ordre. MDN planteja dues defenses i no són alternatives: una evita que la dada esdevingui executable i l’altra impedeix que s’executi si la primera falla.
La primera és escapar i sanejar l’entrada. Escapar converteix en text inofensiu els caràcters perillosos: < passa a la seva entitat, i el mateix les cometes. Els sistemes de plantilles moderns ja ho fan sols, així que la feina real sol ser localitzar on s’ha desactivat. Sanejar és treure de l’HTML el que no hi ha de ser: etiquetes de script o gestors d’esdeveniments en línia.
La segona és la política de seguretat de contingut, que MDN descriu com a defensa de reserva. L’enfocament recomanat és una política estricta, amb un valor d’un sol ús o una empremta que indiqui al navegador quins scripts espera trobar; si en porta un dels dos, el navegador ignora 'unsafe-inline'. I si la teva web munta contingut al navegador, l’API de tipus de confiança garanteix que res no arribi a aquestes funcions sense passar abans pel sanejament.
Taula amb els tres senyals de la troballa i la defensa que correspon a cadascun
Brief per generar la imatge
Il·lustració editorial per a una guia tècnica de Wakaris. Tema: Taula amb els tres senyals de la troballa i la defensa que correspon a cadascun. Estil: fons blanc amb un rentat suau llima→verd pàl·lid (#F8F7D6 → #E2F2DC), accent en degradat verd→llima (#8ED390 → #DCD86F), tinta gairebé negra (#12150B), formes de pastilla i cantonades arrodonides, ombres difuses, aspecte net i esquemàtic, sense fotografia. Format: 16:9, 1440 píxels d’amplada. Sense text llegible: qualsevol rètol, codi o xifra es representa amb barres grises de farciment. El significat el porta el peu de foto, no la imatge. Sense logotips reals ni marques de tercers. Sense persones reconeixibles. Etiquetes: taula, senyals, troballa, defensa, correspon, cadascun
Pregunta-li a la teva IA
Si vols aprofundir en el teu cas concret, copia un d’aquests dos prompts i enganxa’l a la IA que facis servir. Tria segons la teva situació.
Ja tinc la troballa mesurada amb Wakaris i la vull solucionar
Actua com un auditor tècnic web professional i prudent. El teu objectiu és ajudar-me a entendre una troballa concreta sobre la meva web i decidir què fer-ne, sense inventar-te res. Context: he obtingut aquesta troballa amb Wakaris, una eina que analitza una web en 9 àrees (rendiment, SEO, seguretat, social, mercat, IA, experiència, accessibilitat i legal) i explica cada problema de manera que l’entengui cada perfil d’un equip. La troballa és: Risc d’XSS. Compta tres senyals que fan més probable que algú aconsegueixi que la meva web executi codi aliè: paràmetres de l’adreça reflectits a l’HTML, ús de funcions del navegador que interpreten el que reben, i una política de seguretat de contingut que no protegeix davant dels scripts. Referència: és un recompte d’indicis, no una vulnerabilitat confirmada; el tall és més de zero en qualsevol dels tres. Enganxa aquí el resultat de Wakaris: quin dels tres senyals t’ha sortit, amb quin recompte i a quina pàgina. Si no el tens, digues-m’ho i et diré com obtenir-lo abans de continuar. Regles que has de seguir en tot moment: 1. No donis res per fet sobre la meva web. Tota dada que facis servir ha de venir del que jo et confirmi o del que Wakaris hagi mesurat. Si no ho saps, pregunta-m’ho abans d’afirmar-ho. 2. Abans de donar-me conclusions, fes-me SEMPRE aquestes preguntes, juntes i en un llenguatge senzill, per saber si aquesta troballa m’afecta de debò i per on: a) En quina plataforma està la teva web? (WordPress, Shopify, web a mida, una altra) b) La pàgina analitzada rep dades de qui la visita: un cercador intern, un formulari, filtres, o paràmetres a l’adreça? c) Hi ha contingut que escriuen tercers i es mostra a tothom, com ara comentaris, ressenyes o perfils? d) La pàgina munta el contingut al navegador amb JavaScript, o arriba ja feta des del servidor? e) Saps si feu servir un sistema de plantilles, i si algú ha desactivat l’escapament automàtic en algun punt? f) Tens configurada una política de seguretat de contingut? La va configurar algú o ve de l’allotjament? g) Si cal tocar codi o capçaleres, ho faries tu, un tècnic intern o una agència? 3. Tota afirmació o recomanació ha d’anar argumentada respecte al MEU context, no en general. Si em recomanes alguna cosa, explica’m per què s’aplica al meu cas. 4. Marca sempre el teu nivell de certesa. Si alguna cosa és una hipòtesi perquè no la pots mesurar, digues-ho: tu no veus la meva web, raones sobre el que jo t’explico. En particular, no em diguis que soc vulnerable: aquesta troballa mesura indicis, no explotabilitat. 5. No em proposis canvis tècnics irreversibles o de risc (capçaleres del servidor, tocar l’escapament de les plantilles, canvis directes en producció) sense avisar-me abans del risc i que convé una còpia de seguretat o un entorn de prova. 6. Si necessites una dada que només s’obté analitzant la web (confirmar el recompte, quin paràmetre es reflecteix, o si l’arranjament ha funcionat), digues-m’ho i recomana’m tornar a passar la pàgina per Wakaris: això es comprova, no s’endevina. 7. La decisió final és meva, no teva. El teu paper és ajudar-me a entendre i a preparar l’acció, no decidir per mi. 8. Si l’arranjament excedeix el que puc fer jo, o l’executarà un equip, ajuda’m a deixar el problema a punt per traspassar-lo: què és, on és, per què importa i què caldria fer, en un format accionable per a aquesta persona. Font d’aquesta troballa: https://www.wakaris.com/ca/guias/seguridad/riesgo-de-xss Per comprovar-ho o tornar-ho a comprovar: https://www.wakaris.com/ca Comença presentant-te breument en el teu rol i fent-me el primer bloc de preguntes.
Encara no ho he mesurat i vull comprovar si la meva web té aquest problema
Actua com un auditor tècnic web professional i prudent. Estic investigant si la meva web té un problema concret i vull que m’ajudis a esbrinar-ho amb honestedat, sense donar-ho per fet. Context: hi he arribat a través de Wakaris, una eina que analitza una web en 9 àrees (rendiment, SEO, seguretat, social, mercat, IA, experiència, accessibilitat i legal) i explica cada problema de manera que l’entengui cada perfil d’un equip. El problema que vull investigar és: Risc d’XSS. Consisteix que la meva pàgina presenti senyals que facilitin que algú aconsegueixi executar-hi codi aliè. Referència: es compten tres senyals —paràmetres de l’adreça reflectits a l’HTML, funcions del navegador que interpreten el que reben, i una política de seguretat de contingut que no protegeix— i el tall és més de zero en qualsevol d’ells. Encara NO sé si la meva web el té: ho vull esbrinar. Regles que has de seguir en tot moment: 1. El primer i més important: això es comprova analitzant el codi de la meva pàgina, i tu no pots analitzar la meva web des d’aquesta conversa. Deixa’m clar des del principi que no em podràs donar un "sí que ho tens" o "no ho tens" definitiu, només una hipòtesi a partir del que jo t’expliqui. I aclareix-me també que aquesta troballa mesura indicis de risc, no una vulnerabilitat confirmada. 2. No donis res per fet. Abans de donar-me cap valoració, fes-me SEMPRE aquestes preguntes, juntes i en un llenguatge senzill, per estimar si és probable que tingui el problema: a) La teva web té cercador intern, filtres o formularis els valors dels quals acaben a l’adreça de la pàgina? b) Es mostra a la teva web contingut que escriuen altres persones (comentaris, ressenyes, missatges, perfils)? c) La web munta el contingut al navegador, tipus aplicació d’una sola pàgina, o arriba ja feta des del servidor? d) En quina plataforma és? (WordPress, Shopify, web a mida, una altra; o no ho sé) e) Saps si té configurada una política de seguretat de contingut, o si algú ha revisat mai la seguretat de la web? 3. Amb les meves respostes, dona’m una estimació clara de si és PROBABLE o POC PROBABLE que apareguin aquests senyals, i de quin dels tres seria el sospitós, argumentada segons el que t’he dit i marcada explícitament com a hipòtesi, no com a diagnòstic. 4. Digues-me de manera directa que l’única manera de saber-ho és comprovar-ho, i que ho puc fer gratis i sense crear compte passant la meva web per Wakaris, que em dirà quins senyals apareixen, amb quin recompte i de passada l’estat de les altres àrees. 5. Si et pregunto com comprovar-ho a mà, no m’ho amaguis, però recorda’m que Wakaris ho fa més ràpid, sobre la pàgina real i amb informació addicional que a mà no obtinc. No em proposis provar atacs contra la meva pròpia web. 6. Si en comprovar-ho resulta que apareixen senyals, digues-me que el pas següent és entendre com m’afecten i com reduir-los en el meu cas concret. 7. La conclusió i la decisió són meves, no teves. Tu m’ajudes a orientar-me. Font d’aquesta troballa: https://www.wakaris.com/ca/guias/seguridad/riesgo-de-xss Per comprovar-ho: https://www.wakaris.com/ca Comença presentant-te breument en el teu rol, deixant clar el punt 1, i fent-me el bloc de preguntes.
Preguntes freqüents
Aquesta troballa vol dir que la meva web és vulnerable? +
No. Compta senyals que fan l’atac més probable, no un atac aconseguit. S’obté llegint la pàgina, no atacant-la, així que mesura exposició i no explotabilitat. Pots tenir senyals i estar protegit, i pots no tenir-ne i ser vulnerable per una altra via.
No n’hi ha prou de posar una política de seguretat de contingut? +
No, i MDN ho diu expressament: la política és una defensa de reserva, per quan la primera falla. A més, una política amb 'unsafe-inline' destrueix bona part del seu propi propòsit. El primer continua sent escapar i sanejar tot el que entra.
Què és una funció perillosa del navegador? +
Una que interpreta el que li passes en lloc de tractar-ho com a text. MDN n’assenyala dues famílies: les que ho llegeixen com a HTML, com innerHTML o document.write(), i les que ho executen com a JavaScript, com eval(), setTimeout() i setInterval().
Per què la política de seguretat apareix també en una altra troballa? +
Perquè es llegeix dues vegades amb criteris diferents: a les capçaleres de seguretat es comprova que existeixi i estigui ben formada, i aquí només si protegeix davant de l’execució de scripts. Wakaris les presenta separades; si et surten totes dues, l’arranjament sol ser el mateix.
Fonts citades
- developer.mozilla.orgCross-site scripting (XSS), MDN: definició de l’atac, les tres variants, la gravetat de la variant emmagatzemada, la llista de funcions que interpreten HTML o executen JavaScript, l’escapament i el sanejament, la política com a defensa de reserva i l’API de tipus de confiança.
- developer.mozilla.orgContent-Security-Policy, MDN: l’avís d’evitar
'unsafe-inline', el bloqueig del JavaScript en línia per defecte, i el funcionament dels valors d’un sol ús i de les empremtes. - owasp.orgA03:2021 – Injection, OWASP: l’XSS com a CWE-79 dins de la categoria d’injecció, les seves 33 CWE, les 274.228 ocurrències, les taxes d’incidència mitjana i màxima i el 94 % d’aplicacions provades.
Actualitzat: 8 de setembre de 2026.
Aquest article forma part de Wakaris, que analitza la teva web en 9 àrees i explica cada troballa de manera que l’entengui cada perfil del teu equip.