"Mi sitio es seguro, tiene el candadito verde." Ya escuchamos esa frase de decenas de dueños de negocio, y cada vez tenemos que explicar lo mismo: el candado del navegador es prácticamente irrelevante para la seguridad real de tu sitio.
No es que no sirva para nada. Es que protege algo bien específico, y deja afuera prácticamente todo lo que realmente compromete un sitio.
Qué hace realmente el SSL/TLS
El certificado SSL (hoy técnicamente TLS) cifra la conexión entre el navegador de quien visita y el servidor del sitio. Esto impide que alguien "en el medio del camino" (en una red wifi pública, por ejemplo) lea los datos mientras viajan. Es importante, sobre todo si el sitio tiene formulario, login o cualquier envío de datos.
Pero es solo eso. El candado no dice nada sobre lo que pasa después de que el dato llega al servidor, ni sobre cómo fue construido el sitio en sí.
Analogía simple: el SSL es el sobre lacrado del correo. Garantiza que nadie abre la carta en el camino. No garantiza nada sobre quién va a abrir la carta del otro lado, ni si la casa de quien la recibe tiene la puerta sin llave.
Qué NO protege el candado verde
| Riesgo real | ¿El SSL protege? | Qué protege de verdad |
|---|---|---|
| SQL Injection (el atacante manipula la base de datos vía formulario) | No | Prepared statements en el código, nunca concatenar entrada del usuario directo en la query |
| Fuerza bruta en el login (intento automatizado de contraseña) | No | Bloqueo de intentos por IP, límite de intentos, autenticación en dos pasos |
| Panel administrativo expuesto públicamente | No | Autenticación obligatoria, sesiones aisladas, ocultar rutas sensibles |
| Contraseña guardada en texto plano en la base de datos | No | Hash de contraseña (nunca reversible), nunca almacenar contraseña "pura" |
| Filtración de datos por falla de configuración del servidor | No | Headers de seguridad, carpetas sensibles fuera del área pública del servidor |
El caso clásico: sitio "seguro" que fue vulnerado
Vemos esto con frecuencia: un negocio contrata una plataforma cualquiera, obtiene el SSL gratis (hoy es prácticamente estándar en cualquier hosting), se siente seguro, y nunca más piensa en el tema. Meses después, el formulario de contacto empieza a recibir spam masivo, o peor: alguien descubre que el panel de admin era accesible directamente por una URL previsible, sin ninguna protección contra intentos repetidos de contraseña.
Ninguno de esos problemas tiene relación con el SSL. Todos tienen relación con cómo fue construido el sitio.
Qué protege realmente un sitio (y los datos de quien lo usa)
- Prepared statements / consultas parametrizadas: la defensa estándar contra SQL Injection, nunca armar un comando de base de datos concatenando texto ingresado por el usuario
- Hash de contraseña: la contraseña nunca queda guardada "pura" en la base de datos: si la base se filtra, la contraseña sigue protegida
- Límite de intentos de login: bloquea automáticamente a quien intenta adivinar la contraseña repetidamente
- Autenticación en dos pasos (2FA): aunque la contraseña se filtre, el login sigue protegido por un segundo factor
- Headers de seguridad (CSP, HSTS, X-Frame-Options, entre otros): le indican al navegador que bloquee categorías enteras de ataque antes incluso de que ocurran
- Separación de archivos sensibles del área pública del servidor: configuración y credenciales nunca accesibles por URL directa
- Actualización de dependencias: un plugin o librería desactualizada es una de las puertas de entrada más comunes para un ataque
Preguntas que puedes hacerle a tu desarrollador hoy
No necesitas entender de código para exigir esto. Pregunta, directo:
- ¿Las contraseñas de los usuarios se almacenan con hash, o en texto plano?
- ¿Existe límite de intentos de login? ¿Qué pasa si alguien intenta adivinar la contraseña repetidas veces?
- ¿El panel administrativo tiene alguna capa extra de protección, o solo la contraseña?
- ¿Las consultas a la base de datos usan prepared statements?
- ¿El sitio tiene headers de seguridad configurados?
Si la respuesta es un silencio incómodo o "eso es muy técnico, no hace falta preocuparse", conviene desconfiar.
El SSL es un requisito básico, no un diferencial. La seguridad de verdad empieza después del candado, en la forma en que el sitio fue escrito.
Esto vale todavía más si el sitio guarda algún dato personal de cliente: nombre, correo, teléfono, dirección. Además de ser buena práctica, es lo que exige la protección de datos en la práctica: medidas técnicas adecuadas de protección, no solo una política de privacidad bonita en el pie de página.
Preguntas frecuentes
¿El candado verde del navegador significa que mi sitio es seguro?
No del todo. El SSL cifra solo la conexión entre el navegador y el servidor. No protege contra SQL Injection, fuerza bruta en el login, panel administrativo expuesto o contraseña guardada en texto plano.
¿Qué protege realmente un sitio además del SSL?
Prepared statements en la base de datos, hash de contraseña, límite de intentos de login, autenticación en dos pasos, headers de seguridad y actualización constante de dependencias.
¿El SSL es obligatorio aunque no sea suficiente por sí solo?
Sí, es un requisito básico y prácticamente estándar en cualquier hosting hoy. Solo no debe tratarse como sinónimo de seguridad completa.