Un formulario con adjuntos puede facilitar una solicitud de presupuesto, una devolución, una candidatura o una incidencia técnica. Sin embargo, cada archivo recibido abre un recorrido que no termina en el navegador: puede pasar por la aplicación web, WordPress, el almacenamiento, una plataforma de soporte, un CRM o una automatización. Si ese recorrido no está definido, un adjunto legítimo puede provocar errores operativos o exponer sistemas que no estaban preparados para recibirlo.
El objetivo no debería ser aceptar cualquier archivo y reaccionar después, sino permitir únicamente los adjuntos imprescindibles para cada proceso. Este enfoque equilibra experiencia y protección: la persona usuaria conoce las reglas antes de enviar el formulario y la empresa dispone de controles consistentes para validar, guardar, compartir y eliminar los documentos.
El problema es aceptar más adjuntos de los necesarios
No todos los formularios necesitan la misma capacidad de carga. Un contacto comercial quizá requiera una imagen o un PDF para evaluar un proyecto; una devolución puede necesitar fotografías; una candidatura puede necesitar un currículum. En cambio, un formulario de suscripción o una consulta breve normalmente no necesita archivos. Inventariar todos los puntos de carga, incluidos los creados por plugins, áreas privadas y herramientas de soporte, ayuda a eliminar adjuntos superfluos antes de añadir controles técnicos.
OWASP recomienda una defensa en profundidad: limitar las extensiones a las necesarias para la función de negocio, restringir la carga a usuarios autorizados cuando corresponda, establecer límites de tamaño y guardar los ficheros fuera del directorio público de la aplicación o en un host separado. Estas medidas deben considerarse como un conjunto, no como una única comprobación de extensión. [1]
- Revise formularios de contacto, soporte, devoluciones, candidaturas y portales privados.
- Elimine la carga de archivos cuando una descripción, un número de pedido o un enlace seguro resuelva el proceso.
- Distinga entre formularios públicos, formularios autenticados y procesos internos.
Cree un contrato de carga para cada proceso
La medida más útil es crear una ficha sencilla por formulario: finalidad del adjunto, formatos admitidos, peso máximo por archivo, número máximo de ficheros, personas autorizadas, destino de almacenamiento, plazo interno de conservación y responsable del proceso. Este contrato convierte una opción genérica de “adjuntar archivo” en una regla operativa que tecnología, marketing y atención al cliente pueden revisar conjuntamente.
Por ejemplo hipotético, un formulario de devolución podría admitir hasta tres imágenes para documentar el estado de un producto, mientras que un formulario de soporte podría admitir un PDF o una captura de pantalla. No conviene copiar los mismos límites en ambos casos: deben derivarse de lo que una persona necesita aportar para completar esa gestión, de la capacidad técnica disponible y de las herramientas que recibirán el archivo después.
- Documente una justificación breve para cada formato permitido.
- Defina quién puede descargar cada adjunto y en qué contexto.
- Asigne un responsable que revise cambios de plugins, integraciones o requisitos del proceso.
Valide en varias capas y comunique errores claros
La extensión que ve la persona usuaria no basta para decidir si un archivo es aceptable. La aplicación debe aplicar una lista corta de formatos permitidos, tratar con cuidado nombres anómalos o codificados, comprobar el tipo y, cuando sea adecuado, la firma del archivo. También debe generar un nombre interno propio en lugar de reutilizar el nombre enviado. Así se reduce la dependencia de datos controlados por quien realiza la carga. [1]
Los límites deben existir de forma coherente en el navegador, la aplicación, el servidor, el almacenamiento y la integración posterior. OWASP identifica como riesgo la ausencia de límites de tamaño, tiempo, memoria u operaciones, y recomienda limitar también la frecuencia según las necesidades de cada endpoint. Cuando una petición supera el tamaño admitido, el código HTTP 413 permite comunicar que el servidor no la procesará; el mensaje mostrado debe indicar el máximo o los formatos permitidos sin revelar detalles internos. [2] [3]
- Aplique un límite individual y un máximo de adjuntos por envío.
- Evite procesar o descomprimir archivos sin controlar los recursos que esa tarea puede consumir.
- Explique cómo corregir el envío: por ejemplo, reducir el tamaño o elegir un formato permitido.
Separe recepción, almacenamiento e integración
Un archivo recibido no debería quedar públicamente accesible ni ser ejecutable por defecto. Es preferible almacenarlo fuera del directorio público de la web y ofrecer descargas mediante un mecanismo que compruebe permisos y relación con el caso correspondiente. Esta separación es especialmente importante si el sitio usa WordPress, una tienda online o componentes de terceros: la comodidad de enlazar directamente un archivo no debe sustituir el control de acceso. [1]
Antes de reenviar un adjunto a un CRM, una mesa de ayuda o una automatización, confirme que solo se transmite un archivo ya validado y asociado a un identificador de operación. Si falla el destino externo, el flujo debe registrar el estado y permitir una recuperación controlada, sin duplicar envíos ni perder el vínculo con la solicitud original. En formularios autenticados que cambian el estado de la aplicación, también deben contemplarse medidas frente a solicitudes forjadas, como tokens, validación de origen u otros controles adecuados a la arquitectura. [4]
- No publique URL predecibles para descargar adjuntos.
- Mantenga permisos separados para quien recibe, revisa y descarga documentos.
- Pruebe qué ocurre si el CRM o el sistema de soporte no responde.
Registre, pruebe y mejore sin afectar al negocio
Para investigar fallos e incidencias, registre el cuándo, dónde, quién y qué del evento: identificador de solicitud, formulario, resultado de validación, motivo de rechazo, tamaño, tipo detectado, destino y estado de procesamiento. OWASP incluye la carga y el procesamiento de contenido aportado por usuarios entre los eventos relevantes para registro y supervisión. No es necesario almacenar el contenido del adjunto en los registros; hacerlo puede aumentar la exposición de información sensible. [5]
Antes de activar cambios, pruebe en un entorno autorizado o dentro de un alcance expresamente acordado. Use archivos inocuos para verificar una carga válida, un archivo demasiado grande, un formato no permitido, un nombre anómalo y un fallo simulado del destino externo. Revise después los mensajes que recibe la persona usuaria, los registros y la recuperación del proceso. Una auditoría de protección web puede ayudar a revisar este recorrido completo y priorizar correcciones defensivas sin convertir la prueba en una actividad disruptiva.
- Revise periódicamente rechazos repetidos y errores de entrega a sistemas externos.
- Compruebe que los límites coinciden en todas las capas técnicas.
- Actualice la ficha de carga cuando cambie el proceso de negocio o una integración.
Preguntas frecuentes
¿Basta con bloquear extensiones como .exe o .php?
No. Bloquear algunos formatos puede formar parte de la protección, pero no sustituye una lista de formatos necesarios, validaciones del archivo, nombres internos generados por la aplicación, límites de recursos, almacenamiento no público y controles de acceso a las descargas.
¿Qué tamaño máximo debo permitir en un formulario?
No existe un valor universal. Debe responder al uso legítimo del formulario, al número de archivos permitido, a la capacidad de procesamiento y a los límites de los sistemas conectados. Lo importante es aplicar una regla consistente y explicar claramente el límite antes o durante el envío.
¿Puedo enviar automáticamente los adjuntos al CRM?
Sí, si el flujo está diseñado para que la integración reciba únicamente archivos ya validados y pueda rastrear cada operación. Conviene controlar permisos, registrar el estado de entrega y definir qué sucede si el CRM rechaza el archivo o no está disponible.