Volver al blog

Seguridad web

Una ruta práctica por PHP2Shell, XSS, CSRF, formularios, almacenamiento, cabeceras HTTP y dependencias para construir y mantener webs con menos riesgos evitables.

Por Actualizada:

Qué debe revisar un desarrollador para mejorar la seguridad de una web

La seguridad web consiste en reducir riesgos mediante varias capas: validar los datos en el servidor, tratar cada salida según su contexto, comprobar permisos en cada acción, proteger las sesiones y limitar lo que puede ejecutar el navegador. HTTPS es imprescindible, pero no corrige por sí solo un XSS, una autorización rota o una dependencia comprometida.

Esta ruta está pensada para desarrolladores frontend que quieren incorporar seguridad a su proceso sin fingir que una lista sustituye una revisión profesional. Parte de decisiones habituales en formularios, cookies, almacenamiento, dependencias y despliegue, y conecta cada una con una guía más específica.

Ruta de lectura recomendada

Empieza por el modelo general y avanza hacia los puntos donde los datos, la sesión y la configuración cambian el riesgo.

  1. Entender los límites del frontend

    La interfaz puede orientar y validar para mejorar la experiencia, pero el navegador está bajo control del usuario. Estas guías separan validación, codificación de salida y decisiones que deben vivir en el servidor.

  2. Proteger sesiones y datos del navegador

    Elegir entre cookies y almacenamiento web cambia el modelo de amenazas. El objetivo es entender qué puede leer un script, cuándo viajan las credenciales y qué defensa necesita una acción autenticada.

  3. Endurecer la publicación

    Las cabeceras reducen capacidades innecesarias del navegador, las dependencias amplían la cadena de confianza y el runtime del servidor también necesita mantenimiento. Todo se revisa sobre la aplicación real, no copiando una configuración genérica.

Una base mínima antes de publicar

  • Validar en el servidor la forma, el significado y los límites de cada dato recibido.
  • Mostrar datos no confiables como texto y sanear únicamente el HTML que de verdad deba permitirse.
  • Comprobar autorización sobre el recurso y la acción, no solo que exista una sesión.
  • Evitar credenciales y datos sensibles en localStorage o sessionStorage.
  • Configurar cookies, HTTPS y cabeceras según la arquitectura y probar la respuesta desplegada.
  • Revisar dependencias, scripts de instalación y secretos antes de cada publicación.