Lo Esencial en Seguridad de Aplicaciones Web

La mayoría de ataques a las webs de pequeñas empresas no son personales. Son bots automáticos que rastrean todo internet buscando debilidades conocidas y prueban el mismo puñado de cosas en cada dirección que encuentran. Eso es una buena noticia: cubrir los casos habituales te protege de la inmensa mayoría de ataques.

La respuesta corta

HTTPS en todas partes, dependencias al día, formularios protegidos y validados en el servidor, secretos fuera del código, y copias de seguridad automáticas que hayas probado de verdad. Esa lista cubre casi todo el riesgo realista de una web de empresa.

Empieza por lo básico, que es fácil de hacer bien

HTTPS en todas las páginas. No solo en el pago: en todas. Cifra los datos en tránsito, es una señal de posicionamiento, y los navegadores ya marcan el HTTP plano como «no seguro» en la barra de direcciones. Los certificados son gratis y se renuevan solos.

Cabeceras de seguridad. Unas pocas líneas de configuración que le dicen al navegador cómo comportarse a la defensiva:

• Content-Security-Policy: la mejor defensa individual contra el cross-site scripting, porque restringe de dónde pueden venir los scripts
• Strict-Transport-Security: fuerza HTTPS en todas las visitas posteriores
• X-Content-Type-Options: nosniff: impide que el navegador adivine tipos de fichero
• Referrer-Policy: evita filtrar tus URLs a terceros

Puedes comprobar las tuyas gratis en securityheaders.com. La mayoría de webs de empresa sacan una F, y pasar de F a A suele ser una tarde de trabajo.

Mantén las dependencias al día. La inmensa mayoría de las brechas explotan fallos conocidos que se habían corregido meses antes. Un plugin abandonado, una versión antigua de un framework, una librería que nadie actualizó: así se toman las webs. Actualizar no tiene ningún glamour, y es el hábito de seguridad más rentable que existe.

Los formularios son la entrada más habitual

Un formulario público de contacto o presupuesto sin protección es un imán para el spam y el abuso. Nosotros los defendemos por capas, porque ninguna medida basta por sí sola:

• Un campo trampa (honeypot): un campo oculto que una persona nunca ve ni rellena. Los bots lo rellenan todo, así que un honeypot relleno es un bot. Atrapa una parte sorprendente del spam automático y no le cuesta nada al visitante, a diferencia de un CAPTCHA.
• Límite de peticiones: una misma dirección no puede machacar el punto de entrada cientos de veces por minuto.
• Validación en el servidor: siempre. La validación del navegador es una comodidad para el usuario honesto; quien envía una petición directamente se la salta sin esfuerzo.
• Límites de tamaño: en cada campo y en la petición entera.

Nunca te fíes de lo que entra

Esta es la disciplina que por sí sola evita categorías enteras de ataque. Todo dato que envíe un usuario debe validarse y limpiarse en el servidor antes de usarse o guardarse.

• La inyección SQL se evita con consultas parametrizadas, nunca pegando la entrada del usuario dentro de una consulta.
• El cross-site scripting se evita escapando la salida según el contexto en el que aterriza, más una Content-Security-Policy estricta.
• El control de acceso roto —el fallo grave más frecuente en la práctica— se evita comprobando en el servidor que este usuario puede ver este registro. Esconder un botón no es control de acceso: cualquiera puede llamar a la URL directamente.

Mantén los secretos fuera del código

Las claves de API, las contraseñas de base de datos y los tokens van en variables de entorno, nunca en el repositorio. Un secreto subido a git está comprometido aunque lo borres en el commit siguiente, porque el historial lo conserva. Si ha pasado, rota la clave: borrar la línea no basta.

La parte aburrida que te salva

Copias de seguridad. Automáticas, diarias y guardadas en un sitio separado de la propia web. El detalle crucial que la gente se salta: una copia que nunca has restaurado no es una copia, es una esperanza. Prueba una restauración al menos una vez.

Monitorización. Comprobaciones de disponibilidad y alertas de error hacen que te enteres del problema antes que tus clientes. Enterarte por un cliente molesto cuesta más que cualquier servicio de monitorización.

Higiene de accesos. Contraseñas únicas en un gestor, doble factor sobre todo en tu registrador de dominios, tu alojamiento y tu correo, y cuentas antiguas eliminadas cuando alguien deja de trabajar contigo.

Si te tomas WordPress en serio

La mayoría de webs que nos piden rescatar son instalaciones de WordPress donde un plugin fue la puerta de entrada. Si tienes una: mantén pocos plugins y con las versiones al día, elimina por completo los desactivados en vez de dejarlos en disco, usa un nombre de administrador que no sea evidente, y pon doble factor en el acceso. El problema no es la plataforma, sino la superficie acumulada y sin mantener que se le va añadiendo.

Qué hacer si crees que te han entrado

Saca la web de línea o ponla en mantenimiento, en vez de dejar una página comprometida sirviendo a los visitantes. Cambia las contraseñas, empezando por el alojamiento y el correo. Restaura una copia anterior al incidente. Solo entonces averigua cómo entraron y ciérralo, porque restaurar sin tapar el agujero únicamente reinicia el reloj.

La seguridad es un hábito, no un producto

No es algo que compres una vez: es un conjunto de prácticas integradas en cómo se hace y se mantiene la web. Nosotros las incorporamos por defecto —HTTPS, cabeceras estrictas, formularios protegidos y validados, secretos en variables de entorno, actualizaciones de dependencias, copias de seguridad y monitorización en todos los proyectos— para que estés protegido sin tener que pensar en ello.