Un formulari de contacte pot semblar una peça senzilla d'un web, però sovint és l'entrada a processos interns rellevants. Una sol·licitud de pressupost pot crear un contacte al CRM, avisar vendes, obrir una tasca, enviar correus i emmagatzemar documents. Si el flux accepta dades inesperades, repetides o manipulades, el problema no es limita a la safata d'entrada: pot afectar la qualitat de les dades i la càrrega operativa de diversos equips.
Protegir formularis web exigeix mirar tot el recorregut, des de la persona que envia les dades fins a l'última integració que les processa. La prioritat no és impedir qualsevol enviament, sinó definir què s'accepta, quina acció pot desencadenar i quan ha d'intervenir una revisió humana. Així es redueixen el correu brossa, els errors i les automatitzacions que s'executen fora de les regles de negoci.
El formulari és una porta d'entrada a operacions internes
El risc creix quan el formulari es tracta només com un element de disseny o de captació. Els seus camps poden alimentar el correu, el CRM, les plataformes de suport, l'emmagatzematge de fitxers o els automatitzadors. Cada destinació afegeix una decisió: quines dades rep, amb quins permisos i què passa si arriba una sol·licitud no vàlida. Un flux segur també ha de preveure les conseqüències posteriors a l'enviament.
Exemple hipotètic: una empresa rep sol·licituds de distribució mitjançant un formulari. Cada enviament crea un contacte, assigna una tasca prioritària i adjunta documentació a l'expedient. Si no hi ha controls de volum, validació i estats intermedis, una onada de peticions pot omplir el CRM de registres inútils i activar tasques que l'equip ha de revisar manualment. L'objectiu és evitar que la recepció d'una dada es converteixi automàticament en una acció definitiva.
- Comenceu identificant l'URL i la finalitat de cada formulari.
- Anoteu els camps recollits i descarteu els que no siguin necessaris.
- Enumereu les destinacions: CRM, correu, tiquets, ERP, emmagatzematge i API externes, si n'hi ha.
Inventarieu el flux abans d'afegir controls
Un inventari breu ajuda a detectar formularis antics, duplicats o integracions de les quals ja no està clar qui n'és responsable. Per a cada flux, documenteu el compte tècnic o el mecanisme d'autenticació utilitzat, les accions automàtiques que s'activen, qui n'és responsable des de negoci i tecnologia, i quins registres hi ha per investigar incidències. Aquest mapa permet prioritzar els formularis que creen registres, envien missatges o accepten fitxers.
Després, convertiu cada camp en un contracte d'entrada. Definiu si és obligatori, el seu tipus, format, longitud màxima, interval permès i relació amb altres camps. OWASP recomana aplicar la validació al servidor i distingir entre la validació sintàctica, que comprova si el format és l'esperat, i la semàntica, que verifica si la dada té sentit per a l'operació. Les comprovacions visuals o de JavaScript poden millorar l'experiència, però no han de ser l'única barrera. [1]
- Incloeu la mida màxima de la petició i de cada fitxer adjunt.
- Identifiqueu els camps que intenten influir en permisos, preus, estats o assignacions.
- Reviseu l'inventari quan canviïn el proveïdor, el CRM, un connector o l'automatització.
Apliqueu controls en l'ordre que redueix més impacte
Primer, valideu i limiteu. Rebutgeu al servidor valors fora de format, longituds excessives, opcions no publicades o combinacions incoherents. Afegiu límits de freqüència i de mida segons la funció: no necessita el mateix tractament un formulari de contacte que una operació que genera un PDF, consulta un servei extern o crea un tiquet. Per a les API, OWASP aconsella no confiar en paràmetres rebuts, limitar la mida de les peticions, rebutjar contingut inesperat i registrar errors de validació; el codi 429 es pot utilitzar quan s'aplica una limitació de sol·licituds. [2]
Segon, separeu la recepció de l'execució d'accions sensibles. Un enviament pot quedar com a «rebut» o «pendent de revisió» abans de crear un compte, assignar prioritat, emetre comunicacions o actualitzar un registre rellevant. Calculeu al servidor els valors que determinen permisos, propietaris, preus o estats; no accepteu com a definitius els valors que arriben des de camps ocults o des del navegador. Aquesta separació ofereix a l'equip un punt de control quan l'impacte operatiu ho justifica.
- Establiu límits específics per a l'enviament de correu, la creació de tiquets i les crides a serveis externs.
- Oferiu missatges d'error clars sense revelar detalls interns del sistema.
- Conserveu registres d'errors i resultats amb accés restringit per facilitar-ne la revisió.
Tracteu els fitxers adjunts, les sessions i les integracions com a components separats
Els fitxers adjunts requereixen regles pròpies. Si no són imprescindibles per al procés, és raonable desactivar aquesta funció. Quan sí que ho siguin, definiu extensions justificades, valideu el tipus real i la mida, genereu el nom des de l'aplicació i eviteu emmagatzemar-los en una ubicació pública des d'on es puguin servir o executar. OWASP adverteix que la capçalera Content-Type no és suficient per si sola per decidir si un fitxer és acceptable. [4]
Les integracions també han de tenir controls específics. Utilitzeu credencials separades i amb els permisos mínims necessaris per a cada connexió, i retireu o roteu els secrets quan canviï el flux o la persona responsable. En webhooks entrants, verifiqueu la signatura abans de processar l'esdeveniment. Registreu dades operatives com ara l'hora, el tipus d'esdeveniment, el resultat i la latència, però no cossos complets, secrets ni capçaleres d'autorització. Si una operació utilitza galetes de sessió, SameSite pot ajudar, tot i que no substitueix les defenses específiques davant de sol·licituds falsificades entre llocs, com ara tokens adequats [5] [3]
- Restringiu qui pot descarregar documents enviats mitjançant formulari.
- Alerteu davant de pics d'errors de validació, errors de signatura o creació inusual de registres.
- Considereu una política CSP amb connect-src com a control complementari per limitar les destinacions de connexió iniciades per JavaScript al
Reviseu tot el recorregut mitjançant una auditoria autoritzada
Una auditoria de protecció web ha d'acordar per escrit l'abast, els sistemes autoritzats i el mètode de treball abans de qualsevol comprovació. Pot revisar l'inventari de formularis i endpoints, les regles de validació al servidor, els límits de freqüència i mida, la gestió de fitxers adjunts, els permisos de les credencials i la qualitat dels registres. El propòsit és identificar correccions defensives i prioritzar-les, no fer proves sobre sistemes aliens ni fora de l'abast aprovat.
La pregunta final per a cada formulari és senzilla: si algú envia la dada moltes vegades, fora de seqüència o amb una estructura inesperada, quins sistemes interns s'activen i què ho atura? Documentar la resposta, implementar-la al servidor i revisar-la després de cada canvi rellevant converteix la seguretat del formulari en una decisió operativa sostenible. Quan el flux incorpora automatització o IA, definiu també quins permisos té, com s'avaluen les seves sortides, quins límits aplica i en quins casos exigeix revisió humana abans d'actuar.
- Prioritzeu els fluxos que generen accions irreversibles o d'alt volum.
- Assigneu responsables per corregir les troballes i revisar les alertes.
- Verifiqueu que els missatges externs siguin genèrics i que els detalls tècnics romanguin en registres protegits.
Preguntes freqüents
És suficient validar els camps amb JavaScript al navegador?
No. Aquesta validació pot orientar la persona usuària, però les regles rellevants també s'han d'aplicar al servidor. Allà s'han de comprovar el format, la longitud, els valors permesos i la coherència amb el procés abans d'enviar dades a altres sistemes.
Quan convé demanar revisió humana abans d'automatitzar?
Convé quan l'enviament crea un compte, modifica un estat important, genera un compromís operatiu, assigna una prioritat o pot produir un efecte difícil de revertir. Un estat intermedi permet revisar la dada abans d'executar l'acció.
Què ha d'incloure una revisió de seguretat de formularis?
Com a mínim, l'inventari de formularis i integracions, la validació al servidor, els límits de volum i mida, la gestió de fitxers adjunts, les credencials, la protecció de les operacions amb sessió i els registres disponibles per detectar anomalies.