¿Pasar el sitio a HTTPS evitará la inyección SQL y el XSS?
Respuesta breve
No. HTTPS cifra el canal para que los atacantes no puedan leer ni manipular el tráfico en tránsito, pero la entrada maliciosa llega, se descifra y la procesa tu aplicación igual que antes. La inyección SQL y el XSS son fallos de la capa de aplicación que se corrigen con consultas parametrizadas y codificación de salida, no con cifrado de transporte. El error supone que el cifrado sanea el contenido — no lo hace; el atacante simplemente envía la carga por la conexión HTTPS.
«Ya estamos en HTTPS, así que somos seguros» es uno de los mitos más tenaces de la seguridad web. HTTPS es esencial, pero resuelve un problema completamente distinto de la inyección. Esta pregunta comprueba si un candidato sabe colocar un control en la capa correcta.
Qué hace HTTPS realmente
TLS (la S de HTTPS) aporta tres cosas en el camino de red: confidencialidad (los espías no pueden leer el tráfico), integridad (no se puede modificar en silencio en tránsito) y autenticación del servidor. Eso derrota los ataques de hombre en el medio, el sniffing de paquetes en Wi-Fi hostil y el robo de credenciales por la red. Es un control de la capa de transporte. No dice nada sobre si los datos dentro de la petición son seguros de procesar.
Por qué la inyección queda intacta
La inyección SQL y el XSS son fallos de la capa de aplicación. El atacante envía una entrada como ' OR 1=1 -- o <script>...</script> a través de un formulario o llamada a la API perfectamente normales. Bajo HTTPS, esa carga se cifra del navegador al servidor, luego se descifra en el servidor y se entrega a tu código igual que un valor benigno. Si tu código la concatena en una cadena SQL, la inyección se dispara; si la refleja en HTML sin codificar, el script se ejecuta en el navegador de la víctima. El cifrado protege la carga de terceros — no impide que la aplicación la maneje mal. La idea de que una carga cifrada «no puede llegar a la base» invierte la arquitectura.
Las defensas correctas
Corrige la inyección donde vive, en el código:
- Inyección SQL: usa consultas parametrizadas / sentencias preparadas para que la entrada se trate siempre como dato, nunca como SQL ejecutable. Añade cuentas de base con mínimo privilegio.
- XSS: aplica codificación de salida según el contexto al renderizar datos de usuario, valida la entrada y despliega una Content-Security-Policy como defensa en profundidad.
HTTPS y estos controles son complementarios, no sustitutos. Despliega ambos. La conclusión: HTTPS asegura la tubería; las consultas parametrizadas y la codificación de salida aseguran el procesamiento. Capas distintas, fallos distintos.
Posibles preguntas de seguimiento
- ¿Qué corrige realmente la inyección SQL a nivel de código, y por qué funciona?
- ¿Qué defensa aborda el XSS, y cómo la respalda la Content-Security-Policy?
- Nombra una clase de ataque que HTTPS sí evite de verdad.