Un formulari amb adjunts pot facilitar una sol·licitud de pressupost, una devolució, una candidatura o una incidència tècnica. Tanmateix, cada fitxer rebut obre un recorregut que no acaba al navegador: pot passar per l’aplicació web, WordPress, l’emmagatzematge, una plataforma de suport, un CRM o una automatització. Si aquest recorregut no està definit, un adjunt legítim pot provocar errors operatius o exposar sistemes que no estaven preparats per rebre’l.
L’objectiu no hauria de ser acceptar qualsevol fitxer i reaccionar després, sinó permetre únicament els adjunts imprescindibles per a cada procés. Aquest enfocament equilibra experiència i protecció: la persona usuària coneix les regles abans d’enviar el formulari i l’empresa disposa de controls consistents per validar, desar, compartir i eliminar els documents.
El problema és acceptar més adjunts dels necessaris
No tots els formularis necessiten la mateixa capacitat de càrrega. Un contacte comercial potser requereix una imatge o un PDF per avaluar un projecte; una devolució pot necessitar fotografies; una candidatura pot necessitar un currículum. En canvi, un formulari de subscripció o una consulta breu normalment no necessita fitxers. Inventariar tots els punts de càrrega, inclosos els creats per plugins, àrees privades i eines de suport, ajuda a eliminar adjunts superflus abans d’afegir controls tècnics.
OWASP recomana una defensa en profunditat: limitar les extensions a les necessàries per a la funció de negoci, restringir la càrrega a persones usuàries autoritzades quan correspongui, establir límits de mida i desar els fitxers fora del directori públic de l’aplicació o en un host separat. Aquestes mesures s’han de considerar com un conjunt, no com una única comprovació d’extensió. [1]
- Reviseu formularis de contacte, suport, devolucions, candidatures i portals privats.
- Elimineu la càrrega de fitxers quan una descripció, un número de comanda o un enllaç segur resolgui el procés.
- Distingiu entre formularis públics, formularis autenticats i processos interns.
Creeu un contracte de càrrega per a cada procés
La mesura més útil és crear una fitxa senzilla per formulari: finalitat de l’adjunt, formats admesos, pes màxim per fitxer, nombre màxim de fitxers, persones autoritzades, destinació d’emmagatzematge, termini intern de conservació i responsable del procés. Aquest contracte converteix una opció genèrica d’«adjuntar fitxer» en una regla operativa que tecnologia, màrqueting i atenció al client poden revisar conjuntament.
Per exemple hipotètic, un formulari de devolució podria admetre fins a tres imatges per documentar l’estat d’un producte, mentre que un formulari de suport podria admetre un PDF o una captura de pantalla. No convé copiar els mateixos límits en tots dos casos: han de derivar d’allò que una persona necessita aportar per completar aquella gestió, de la capacitat tècnica disponible i de les eines que rebran el fitxer després.
- Documenteu una justificació breu per a cada format permès.
- Definiu qui pot descarregar cada adjunt i en quin context.
- Assigneu una persona responsable que revisi canvis de plugins, integracions o requisits del procés.
Valideu en diverses capes i comuniqueu errors clars
L’extensió que veu la persona usuària no n’hi ha prou per decidir si un fitxer és acceptable. L’aplicació ha d’aplicar una llista curta de formats permesos, tractar amb cura noms anòmals o codificats, comprovar-ne el tipus i, quan sigui adequat, la signatura del fitxer. També ha de generar un nom intern propi en lloc de reutilitzar el nom enviat. Així es redueix la dependència de dades controlades per qui fa la càrrega. [1]
Els límits han d’existir de manera coherent al navegador, l’aplicació, el servidor, l’emmagatzematge i la integració posterior. OWASP identifica com a risc l’absència de límits de mida, temps, memòria o operacions, i recomana limitar també la freqüència segons les necessitats de cada endpoint. Quan una petició supera la mida admesa, el codi HTTP 413 permet comunicar que el servidor no la processarà; el missatge mostrat ha d’indicar el màxim o els formats permesos sense revelar detalls interns. [2] [3]
- Apliqueu un límit individual i un màxim d’adjunts per enviament.
- Eviteu processar o descomprimir fitxers sense controlar els recursos que aquesta tasca pot consumir.
- Expliqueu com corregir l’enviament: per exemple, reduir la mida o triar un format permès.
Separeu la recepció, l’emmagatzematge i la integració
Un fitxer rebut no hauria de quedar públicament accessible ni ser executable per defecte. És preferible emmagatzemar-lo fora del directori públic del web i oferir descàrregues mitjançant un mecanisme que comprovi permisos i relació amb el cas corresponent. Aquesta separació és especialment important si el lloc utilitza WordPress, una botiga en línia o components de tercers: la comoditat d’enllaçar directament un fitxer no ha de substituir el control d’accés. [1]
Abans de reenviar un adjunt a un CRM, una taula de suport o una automatització, confirmeu que només es transmet un fitxer ja validat i associat a un identificador d’operació. Si falla la destinació externa, el flux ha de registrar l’estat i permetre una recuperació controlada, sense duplicar enviaments ni perdre el vincle amb la sol·licitud original. En formularis autenticats que canvien l’estat de l’aplicació, també s’han de preveure mesures davant de sol·licituds falsificades, com ara tokens, validació d’origen o altres controls adequats a l’arquitectura. [4]
- No publiqueu URL predictibles per descarregar adjunts.
- Manteniu permisos separats per a qui rep, revisa i descarrega documents.
- Proveu què passa si el CRM o el sistema de suport no respon.
Registreu, proveu i milloreu sense afectar el negoci
Per investigar errors i incidències, registreu el quan, on, qui i què de l’esdeveniment: identificador de sol·licitud, formulari, resultat de validació, motiu de rebuig, mida, tipus detectat, destinació i estat de processament. OWASP inclou la càrrega i el processament de contingut aportat per persones usuàries entre els esdeveniments rellevants per al registre i la supervisió. No cal emmagatzemar el contingut de l’adjunt als registres; fer-ho pot augmentar l’exposició d’informació sensible. [5]
Abans d’activar canvis, proveu-los en un entorn autoritzat o dins d’un abast expressament acordat. Utilitzeu fitxers innocus per verificar una càrrega vàlida, un fitxer massa gran, un format no permès, un nom anòmal i una fallada simulada de la destinació externa. Reviseu després els missatges que rep la persona usuària, els registres i la recuperació del procés. Una auditoria de protecció web pot ajudar a revisar aquest recorregut complet i prioritzar correccions defensives sense convertir la prova en una activitat disruptiva.
- Reviseu periòdicament rebutjos repetits i errors de lliurament a sistemes externs.
- Comproveu que els límits coincideixen en totes les capes tècniques.
- Actualitzeu la fitxa de càrrega quan canviï el procés de negoci o una integració.
Preguntes freqüents
N’hi ha prou de bloquejar extensions com .exe o .php?
No. Bloquejar alguns formats pot formar part de la protecció, però no substitueix una llista de formats necessaris, validacions del fitxer, noms interns generats per l’aplicació, límits de recursos, emmagatzematge no públic i controls d’accés a les descàrregues.
Quina mida màxima he de permetre en un formulari?
No existeix un valor universal. Ha de respondre a l’ús legítim del formulari, al nombre de fitxers permès, a la capacitat de processament i als límits dels sistemes connectats. L’important és aplicar una regla consistent i explicar clarament el límit abans o durant l’enviament.
Puc enviar automàticament els adjunts al CRM?
Sí, si el flux està dissenyat perquè la integració rebi únicament fitxers ja validats i pugui rastrejar cada operació. Convé controlar permisos, registrar l’estat de lliurament i definir què passa si el CRM rebutja el fitxer o no està disponible.