Añadir un campo de adjuntos también exige decidir qué archivos aceptas, dónde se guardan y quién puede consultarlos. El nombre y la extensión no demuestran que un documento sea seguro. Define límites, controles y una vía de revisión antes de reenviarlo o procesarlo; utiliza datos ficticios para comprobar el recorrido completo.
¿Qué cambia cuando tu formulario empieza a recibir archivos?
Un mensaje de contacto describe una necesidad; un adjunto puede incorporar planos, fotografías o documentación que el negocio no debería distribuir sin criterio. El trabajo no termina cuando aparece «subido». Alguien necesita encontrarlo, entender a qué solicitud pertenece y decidir qué herramientas pueden abrirlo. Si el formulario solo manda una copia por correo, la organización puede perder de vista dónde se conserva la información.
Imagina un pequeño estudio de arquitectura que solicita un plano para valorar una reforma. Es un ejemplo hipotético. La persona interesada adjunta el documento y después añade otro desde un segundo envío. El equipo necesita saber cuál está revisando y evitar exponer ambos mediante un enlace público. Antes de programar el campo, conviene definir qué documentos son necesarios en esta primera conversación y cuáles pueden pedirse más adelante.
La guía de subida de archivos de OWASP, consultada el 19 de octubre de 2026, recomienda controles combinados sobre tipos, nombres, tamaños, almacenamiento y procesamiento. No ofrece una marca de seguridad que se obtenga activando una opción. Trata el archivo como una entrada no confiable y pide al responsable técnico que explique los controles efectivos, incluidos sus límites.
Evita pedir «toda la documentación disponible» por comodidad. Eso traslada al visitante una decisión que corresponde al negocio. Describe el propósito del adjunto y una alternativa si no puede aportarlo. En el estudio hipotético, quizá baste una descripción inicial para decidir el siguiente contacto. Reducir lo que se pide puede simplificar el proceso y limitar la información que después habrá que custodiar.
¿Por qué no basta con permitir únicamente PDF?
El control visible en el navegador puede ayudar al usuario a elegir un formato, pero no sustituye la validación en el servidor. La guía de validación de entradas de OWASP advierte de esta diferencia. Un archivo llamado «plano.pdf» sigue necesitando comprobaciones. Ni su nombre ni el tipo declarado por quien lo envía prueban por sí solos el contenido real o su inocuidad.
La selección de formatos debe responder al trabajo. Si el equipo solo necesita visualizar una planta, no conviene aceptar cualquier archivo comprimido o ejecutable. Establece qué admite el servicio y cómo se explica un rechazo. No copies una lista extensa de extensiones de otro formulario sin revisar qué podrá abrir de forma segura el personal. Una aceptación amplia puede generar más trabajo que una petición concreta y comprensible.
Los límites de tamaño también necesitan una explicación visible. Una persona no debería completar una consulta larga para descubrir al final que su archivo no cabe. Indica el formato y el límite configurado antes del envío, conserva el texto cuando se produce un error y explica cómo continuar. El valor elegido depende de la necesidad y de la capacidad técnica; este artículo no propone un tamaño universal para todas las empresas.
Separa una validación fallida de una incidencia de infraestructura. Un archivo no admitido no es lo mismo que una interrupción al guardarlo. El visitante necesita saber si debe cambiar el documento o volver a intentarlo por una vía prevista. No anuncies recepción completa si el archivo no quedó disponible. El equipo debe poder distinguir los casos sin pedir al cliente que reconstruya todo el proceso por teléfono.
¿Dónde debería guardarse y cómo se autoriza el acceso?
La ubicación depende de la aplicación y de sus controles. OWASP recomienda separar el almacenamiento de los archivos de la zona desde la que se ejecuta o sirve la web, cuando corresponda al diseño. Lo importante para el negocio es poder responder a una pregunta sencilla: ¿una persona sin permiso podría recuperar ese documento si consigue el enlace? No presupongas privacidad porque la dirección sea larga o poco intuitiva.
La guía de autorización de OWASP propone comprobar permisos en cada acceso y partir de un criterio restrictivo. En el estudio de arquitectura, quien revisa una solicitud necesita sus documentos; eso no convierte todos los expedientes en visibles para cualquier cuenta. El permiso debe corresponder a una función y a un caso, no solo a haber entrado una vez en el panel.
Decide qué ocurre cuando alguien cambia de función o deja de colaborar. También revisa si existen enlaces incluidos en correos antiguos y qué acceso conservan. Una copia descargada ya no está bajo el mismo control que el archivo del sistema. No es una razón para impedir cualquier trabajo, sino para definir cómo se comparte y cuándo se retiran permisos. El procedimiento debe describir la práctica, no solo la configuración inicial.
La conservación necesita otro criterio: cuánto tiempo se guarda una solicitud que no continúa y quién puede ordenar su retirada. No fijes un plazo copiado de otra actividad. Revisa finalidad, obligaciones y necesidades con quien lleve protección de datos. Este artículo ofrece información general, no asesoramiento jurídico/profesional. Que el formulario solicite consentimiento no resuelve automáticamente todas las condiciones del tratamiento ni legitima cualquier reutilización posterior.
¿Qué sucede antes de abrirlo, reenviarlo o enviarlo a una IA?
El recorrido del adjunto puede incluir análisis técnico, previsualización, correo e interpretación automática. Cada paso debe tener una razón y un responsable. Las comprobaciones no deberían comenzar después de distribuir el documento a varios destinos. Antes de procesar, identifica qué herramienta recibirá los datos y si esa transferencia forma parte del servicio explicado al usuario. No pruebes lectores externos con documentos personales reales por curiosidad.
OWASP menciona controles como análisis antimalware o reconstrucción de contenido cuando resultan apropiados, y advierte de que ninguna comprobación aislada basta. Pide que se delimite qué se analiza y qué ocurre con lo que no puede comprobarse. Un estado «pendiente de revisión» es más honesto que «seguro» si el sistema no tiene evidencia suficiente. Tampoco presentes el antivirus como garantía de que cualquier contenido puede abrirse sin precauciones.
Si se usa IA para extraer datos, separa el documento recibido de las instrucciones que gobiernan la herramienta. No es necesario desarrollar aquí otro agente para resolver la recepción. Puedes empezar con un circuito manual ordenado y una previsualización adecuada. La automatización merece estudiarse cuando haya una necesidad repetida, un entorno autorizado y un criterio claro de qué se espera obtener del archivo.
| Momento | Evidencia útil | Qué evitar |
|---|---|---|
| Envío | Archivo asociado a la solicitud | Confirmar sin conservarlo |
| Validación | Tipo y límites comprobados | Confiar solo en la extensión |
| Consulta | Acceso autorizado al expediente | Enlace público por defecto |
| Procesamiento | Herramienta y finalidad definidas | Reenviar copias indiscriminadas |
¿Cómo probarlo sin usar expedientes de clientes?
Prepara documentos ficticios del tipo que esperas recibir. Incluye uno válido, uno que supere el límite y otro que no pertenezca a un formato admitido. No necesitas crear archivos maliciosos para comprobar los mensajes básicos. El responsable técnico puede diseñar sus pruebas de seguridad en un entorno controlado. El equipo de atención debe revisar que las explicaciones permitan continuar sin perder la consulta.
Comprueba además que una cuenta sin acceso al expediente no pueda abrir el documento y que el enlace funcione para la persona autorizada. Revisa la diferencia entre sustituir una versión y añadir un archivo nuevo. La prueba debe llegar hasta quien trabaja con la solicitud. Un fichero que aparece en una carpeta pero no puede relacionarse con ningún contacto no completa el recorrido que el negocio necesita.
Deja una guía corta para incidencias: cómo reconocer una subida incompleta, a quién escalar un archivo dudoso y qué vía ofrecer cuando el visitante no puede adjuntar. No publiques resultados de seguridad sin una revisión que los sostenga. Una prueba funcional demuestra el comportamiento observado en sus condiciones; no certifica toda la aplicación ni sustituye el mantenimiento de sus componentes.
Cómo lo hemos abordado en meiika
En meiika estudiamos las webs junto al recorrido que continúa después del formulario. Solicitar un archivo afecta a atención, permisos y organización. Antes de añadir el campo, habría que conocer qué información necesita el negocio y quién la utilizará.
Los sistemas a medida permiten plantear esa relación entre solicitud, documento y persona responsable. Aquí describimos criterios de revisión; no afirmamos haber auditado una plataforma concreta ni garantizamos la seguridad de los archivos recibidos.