Production Hardening
El modelo dirigido por el servidor de webforJ y las salvaguardas integradas contra amenazas comunes cubren mucho, pero un despliegue seguro aún depende de cómo operes la aplicación. Los pasos a continuación completan la imagen.
Cifra cada conexión
Ejecuta el tráfico de producción solo a través de HTTPS. Termina TLS en el contenedor, proxy o equilibrador de carga frente a la aplicación, y redirige cualquier solicitud en HTTP plano a su equivalente seguro para que las credenciales y los identificadores de sesión nunca viajen sin cifrar.
No confíes en nada del navegador
Un cliente manipulado puede enviar cualquier cosa. Revalida cada valor que tu código recibe, incluso aquellos valores que tu interfaz ya restringió, antes de persistir o actuar sobre ellos. El artículo sobre la Interacción Cliente/Servidor explica por qué el servidor es el único lugar donde una regla puede sostenerse verdaderamente.
La vinculación y validación de datos de webforJ ayuda aquí: porque la vinculación se ejecuta en Java en el servidor, las restricciones que adjuntas a un modelo, incluida la validación de Jakarta, se hacen cumplir en el lado del servidor en lugar de solo en el navegador. Trata eso como tu capa de integridad, no como una defensa contra ataques de inyección o de marcado, que aún necesitan el manejo descrito en el artículo de Amenazas Comunes.
Deshabilitado y oculto no son seguridad
setEnabled(false) y setVisible(false) son pistas de interfaz, no controles de acceso. webforJ refleja el estado deshabilitado de un control al cliente, pero no impide que un cliente manipulado vuelva a habilitar ese control y active su acción. Nunca confíes en un control deshabilitado u oculto para evitar que algo ocurra.
Pon la verdadera regla en el manejador del lado del servidor en su lugar: confirma que el usuario tiene permiso y que las precondiciones se cumplen antes de realizar la acción, exactamente como lo harías si el control hubiera estado habilitado todo el tiempo. El estado deshabilitado guía a los usuarios honestos; la regla del lado del servidor detiene a los deshonestos.
Asegura tus vistas
Protege las vistas con seguridad de rutas para que cada una demande la autenticación y los roles adecuados. Otorga a las personas el acceso más restringido que les permita trabajar, y prefiere una postura segura por defecto donde una ruta no marcada aún requiera inicio de sesión.
Mantén secretos externos
Las credenciales, claves y tokens no pertenecen al código o a tu repositorio. Obténlos del entorno o de una fuente externa en su lugar, como se muestra en Gestión de Secretos.
Mantente al día con las dependencias
Las bibliotecas que incorporas son una fuente de riesgo mayor que tu propio código. Haz seguimiento de los avisos, actualiza webforJ y tus otras dependencias regularmente, y cuando una versión corregida de una biblioteca transitiva se envíe antes que la biblioteca que la incluye, fija la versión corregida en tu pom.xml.
Falla silenciosamente
No dejes que las trazas de pila, rutas de archivos o identificadores internos lleguen a los usuarios finales. Registra los detalles en tus registros del servidor y presenta un mensaje genérico y simple en la interfaz. Registra un manejador personalizado a través de la manejadora de errores de webforJ para que las excepciones no capturadas muestren una página controlada en lugar de diagnósticos en bruto.
Divulga de manera responsable
¿Encontraste un posible fallo en webforJ mismo? Infórmalo de forma privada a través del informe de vulnerabilidad privado de GitHub en lugar de abrir un problema público o una solicitud de extracción, para que una solución pueda implementarse antes de que se conozcan los detalles.