En resum
Què es comprova
si el formulari envia les dades xifrades i si té alguna protecció davant d’enviaments automàtics.
Quan salta
quan l’enviament és insegur, o quan no hi ha cap protecció antispam.
Per què importa
les dades que algú escriu viatgen llegibles, i el navegador l’hi diu en pantalla.
Severitat a Wakaris
Millora. Apareix al 16,9 % de les pàgines analitzades, xifra interna del catàleg i comptada sobre totes les pàgines, també les que no tenen formularis.
Què és i què comprova aquesta troballa
Wakaris anomena Protecció de formularis la revisió de dues propietats diferents d’un mateix element: on van les dades que algú escriu al teu formulari, i si hi ha alguna cosa que impedeixi que aquest formulari s’ompli sol, milers de vegades, des d’un programa.
La comprovació es basa en tres evidències. La primera registra si la pàgina té formularis, i és la que decideix si les altres dues tenen sentit: en una pàgina sense formularis no hi ha res a protegir. La segona mira l’enviament, és a dir, si les dades surten xifrades o en clar. La tercera mira si existeix alguna protecció davant d’enviaments automàtics.
La troballa es dispara en dues situacions i l’informe et diu quina: l’enviament és insegur, o no hi ha protecció antispam. Són dos problemes de naturalesa molt diferent sota un mateix nom, així que convé llegir l’evidència abans de decidir què fer.
Com es comprova
Wakaris analitza l’URL que li indiquis, localitza els formularis d’aquesta pàgina i et retorna si l’enviament és segur i si hi ha alguna protecció antispam, amb la severitat de la troballa i sense instal·lar res. Aquesta és la via directa per saber en quin punt ets.
Convé saber quin abast té la comprovació, perquè canvia com es llegeix el resultat. Es fa sobre una sola pàgina i una sola càrrega: un formulari que només apareix després d’iniciar sessió, o que es munta més tard des de JavaScript, en queda fora. I comprova presència, no eficàcia: que existeixi una barrera antispam no vol dir que funcioni, igual que un enviament xifrat no garanteix que qui rep les dades les tracti bé.
Hi ha dues coses que la definició del check no concreta i que convé confirmar amb l’equip abans de discutir un resultat: quins mecanismes compta com a protecció antispam vàlida, i si l’enviament es jutja només per l’adreça declarada al formulari o també pel que fa el codi que el processa.
Per què importa
Importa per dos motius que no tenen res a veure entre ells.
El primer és que les dades viatgen llegibles. La documentació de MDN ho diu sense embuts: si el formulari és en una pàgina segura i la seva adreça d’enviament apunta a un URL http insegur, tots els navegadors mostren un avís de seguretat a l’usuari cada vegada que intenta enviar dades, perquè les dades no aniran xifrades. Aquest avís el veu el teu client just quan escriu el seu telèfon. I des del gener de 2017, Chrome marca a més com a no segura qualsevol pàgina que demani una contrasenya o una targeta fora d’un context segur; posar el formulari en un marc https dins d’una pàgina http no n’hi ha prou, perquè la pàgina de primer nivell també ha de ser https.
El segon és l’spam automatitzat, que OWASP cataloga com a amenaça pròpia amb el codi OAT-017: l’addició d’informació maliciosa o qüestionable a continguts o missatges, públics o privats. Inclou programari maliciós, propietat intel·lectual robada, codi de seguiment i contingut publicat per posicionar o per tapar altres publicacions.
Causes habituals
En l’enviament insegur, la causa dominant és una migració a https feta a mitges. La pàgina es va passar a https i l’adreça d’enviament del formulari es va quedar escrita a mà amb http a la plantilla. El formulari continua funcionant, així que ningú no el mira. El segueixen els formularis que envien a un servei extern o a un gestor de contactes antic que només respon per http.
En la manca de protecció antispam hi ha tres patrons. El formulari va néixer com un contacte ràpid i mai no s’hi va afegir res. La barrera va existir i es va treure a propòsit, perquè perdia conversions o es trencava al mòbil. O el que hi ha és validació al navegador: comprovacions que impedeixen enviar el formulari mal omplert, però que un programa se salta enviant les dades directament a la destinació, sense obrir la pàgina.
Com solucionar-ho
Per ordre d’esforç davant de resultat.
Primer, arregla l’adreça d’enviament. Wakaris t’assenyala quin formulari falla; passa-la a https o deixa-la relativa perquè hereti l’esquema de la pàgina. I si recull alguna cosa sensible, no ho enviïs per GET: MDN adverteix que no s’ha de fer servir mai aquest mètode per a una contrasenya, perquè acaba visible a la barra d’adreces.
Segon, posa una barrera que no castigui qui omple el formulari. La nota del W3C sobre la inaccessibilitat dels CAPTCHA recomana els enfocaments no interactius, perquè no plantegen cap repte d’accessibilitat, i cita els camps trampa ocults i el filtratge d’spam al servidor. Si fas servir un desafiament visual, hi ha d’haver alternativa.
Tercer, valida al servidor: la regla de MDN no admet matisos, totes les dades que arriben s’han de comprovar i sanejar sense excepció.
Quart, tanca la porta amb una capçalera. La directiva form-action de Content Security Policy restringeix els URL que poden ser destinació d’un enviament. Després, torna a passar la pàgina per Wakaris.
Taula amb les dues situacions que disparen la troballa, l’evidència associada a cadascuna i l’arranjament corresponent
Brief per generar la imatge
Il·lustració editorial per a una guia tècnica de Wakaris. Tema: Taula amb les dues situacions que disparen la troballa, l’evidència associada a cadascuna i l’arranjament corresponent. 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, situacions, disparen, troballa, evidència, associada, cadascuna, arranjament
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: Protecció de formularis. Revisa els formularis d’una pàgina i comprova dues coses: si envien les dades per una connexió xifrada i si tenen alguna barrera davant d’enviaments automàtics. Referència: la troballa salta quan l’enviament és insegur, o quan no hi ha cap protecció antispam. Enganxa aquí el resultat de Wakaris: quina evidència t’ha sortit en vermell (enviament insegur o manca de protecció antispam), a quina pàgina i, si ho indica, en quin formulari. 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) Quants formularis té la pàgina afectada i per a què serveix cadascun (contacte, alta al butlletí, pressupost, accés amb contrasenya, pagament)? c) Quines dades recull el formulari afectat? Hi ha contrasenyes, dades de pagament, documents d’identitat o dades de salut? d) Saps on envia les dades: a la teva pròpia web, a un servei extern de formularis, a un gestor de contactes o a un correu? e) Té ara mateix alguna protecció contra enviaments automàtics? Saps quina? f) Reps enviaments brossa per aquest formulari? Molts o algun de solt? g) Si cal aplicar un arranjament tècnic, el 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. 5. No em proposis canvis tècnics irreversibles o de risc (configuració de servidor, esborrar recursos, canvis directes en producció) sense avisar-me abans del risc i que convé una còpia de seguretat o un entorn de prova. 6. No em proposis provar el formulari enviant dades personals de tercers ni llançar enviaments massius contra la meva pròpia web per veure si aguanta. Si cal una prova, digues-me com fer-la amb dades inventades i en un entorn de prova. 7. Si necessites una dada que només s’obté analitzant la web (confirmar quin formulari falla, 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. 8. La decisió final és meva, no teva. El teu paper és ajudar-me a entendre i a preparar l’acció, no decidir per mi. 9. Si l’arranjament supera 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/proteccion-de-formularios 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: Protecció de formularis. Es tracta de si els formularis de la meva pàgina envien les dades per una connexió xifrada i de si tenen alguna barrera davant d’enviaments automàtics. Referència: el problema existeix quan l’enviament és insegur, o quan no hi ha cap protecció antispam. 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 llegint el codi de la meva pàgina, i tu no ho pots fer 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. 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é formularis? Quins i en quines pàgines (contacte, butlletí, pressupost, accés, pagament)? b) Quines dades demana cadascun? N’hi ha algun que demani contrasenya o dades de pagament? c) La teva web carrega amb el cadenat del navegador, és a dir, per https? La vas migrar en algun moment des d’http? d) Quan envies el formulari tu mateix per provar-lo, el navegador et mostra algun avís que la informació no és segura? e) Els formularis els va fer la mateixa persona que la web, o vénen d’un servei extern o d’un plugin? f) Reps enviaments brossa per aquests formularis? Quants al dia, més o menys? g) En quina plataforma és la web? (WordPress, Shopify, web a mida, una altra; o no ho sé) 3. Amb les meves respostes, dona’m una estimació clara de si és PROBABLE o POC PROBABLE que el tingui, i de quina de les dues coses seria la sospitosa, 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 de debò és comprovar-ho, i que ho puc fer gratis i sense crear compte passant la meva web per Wakaris, que em dirà quin formulari falla, en quina evidència 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. 6. No em proposis llançar enviaments massius ni proves d’atac contra la meva pròpia web per esbrinar-ho. 7. Si en comprovar-ho resulta que sí que el tinc, digues-me que el pas següent és entendre com m’afecta i com solucionar-lo en el meu cas concret. 8. 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/proteccion-de-formularios 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
Per què em surt aquesta troballa si la meva web ja és https? +
Perquè una cosa és on és la pàgina i una altra on envia el formulari. L’adreça d’enviament pot continuar apuntant a http encara que la pàgina carregui per https. MDN documenta que, en aquest cas, tots els navegadors avisen l’usuari cada vegada que intenta enviar les dades, perquè no aniran xifrades.
N’hi ha prou de validar el formulari al navegador? +
No. Aquesta validació millora l’experiència de qui omple el formulari, però un programa no obre la teva pàgina: envia les dades directament a l’adreça de destinació i mai no executa aquest codi. La comprovació que serveix contra l’spam automatitzat és la que passa al servidor, quan les dades ja han arribat.
He de posar un CAPTCHA per passar aquesta comprovació? +
No necessàriament. El W3C recull que resoldre’n un porta una mitjana de 32 segons i que els enfocaments no interactius, com un camp trampa ocult o el filtratge al servidor, no plantegen cap repte d’accessibilitat. Qualsevol barrera efectiva val, i la que exigeix demostrar que no ets un programa té cost.
Un formulari que envia sense xifrar i un sense antispam són la mateixa troballa? +
Sí, són la mateixa comprovació amb la mateixa severitat, perquè la severitat és un atribut del check i no del cas concret. El que et diu quin dels dos tens és l’evidència que acompanya la troballa a l’informe. L’arranjament, en canvi, no s’hi assembla gens.
Fonts citades
- developer.mozilla.orgSending form data, MDN: l’avís de tots els navegadors quan l’adreça d’enviament és http insegura, la prohibició de GET per a contrasenyes i la regla de comprovar i sanejar tota dada que arriba al servidor.
- developer.mozilla.orgMixed content, MDN: definició de contingut mixt i repartiment entre peticions que el navegador eleva a https i peticions que bloqueja.
- developer.chrome.comAvoiding the not secure warning in Chrome, Chrome for Developers: marcatge com a no segures de les pàgines amb camps de contrasenya o targeta fora de context segur des del gener de 2017, i insuficiència del marc https dins de pàgina http.
- owasp.orgOAT-017 Spamming, OWASP: definició de l’spam com a amenaça automatitzada i tipus de contingut que introdueix.
- w3.orgInaccessibility of CAPTCHA, W3C: mitjana de 32 segons per resoldre un CAPTCHA i recomanació dels enfocaments no interactius, camps trampa i filtratge d’spam.
- developer.mozilla.orgContent-Security-Policy: form-action, MDN: la directiva restringeix els URL que poden ser destinació d’un enviament de formulari.
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.