Seguridad en JavaScript: Cómo proteger tu sitio de inyecciones SQL y XSS

Seguridad en JavaScript: Protección contra inyecciones SQL y XSS — Guía completa para el desarrollador

¿Alguna vez te has preguntado por qué los hackers aman tanto las aplicaciones web? La respuesta es simple: los desarrolladores a menudo dejan las «puertas» abiertas. Los dos agujeros más populares son las inyecciones SQL y el XSS (Cross-Site Scripting). Incluso si escribes en JavaScript, eso no significa que estés protegido contra ataques en el lado del servidor. En este artículo, analizaremos cómo reconocer las vulnerabilidades y, lo más importante, cómo cerrarlas utilizando prácticas de seguridad modernas.

¿Por qué un desarrollador de JavaScript debería pensar en seguridad?

Muchos principiantes piensan: «Escribo en el frontend, no toco bases de datos, no corro peligro». Esto es un error peligroso. Hoy en día, JavaScript funciona en todas partes: en el cliente (navegador), en el servidor (Node.js) e incluso en bases de datos (MongoDB). Por lo tanto, la responsabilidad de la seguridad recae sobre ti. Las inyecciones SQL y el XSS no son solo términos aburridos de los libros de texto, son amenazas reales que pueden destruir tu proyecto, robando datos de usuarios o convirtiendo tu sitio en un foco de virus.

Inyecciones SQL: Una amenaza invisible para tu base de datos

Una inyección SQL es un ataque en el que un atacante «inyecta» código SQL malicioso a través de campos de entrada (formularios, URL, encabezados). Si usas Node.js con PostgreSQL, MySQL o cualquier otra base de datos relacional, estás en la zona de riesgo.

¿Cómo se ve una inyección SQL en JavaScript?

Imagina que tienes un formulario de inicio de sesión y escribes la consulta así:

// ❌ PELIGROSO: vulnerable a inyección SQL\nconst username = req.body.username;\nconst password = req.body.password;\nconst query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;

Ahora imagina que un atacante ingresa en el campo username: admin' --. La consulta se convierte en:

SELECT * FROM users WHERE username = 'admin' --' AND password = '';

-- es un comentario en SQL. Todo lo que sigue se ignora. El hacker inició sesión como administrador sin contraseña. ¿Y si ingresa '; DROP TABLE users; --? ¡Perderías toda la tabla de usuarios!

Protección: consultas parametrizadas (prepared statements)

La mejor manera de protegerse contra las inyecciones SQL es nunca insertar datos de usuario directamente en la cadena de la consulta. Utiliza consultas parametrizadas. Así es como se hace en Node.js con la librería pg (PostgreSQL):

// ✅ SEGURO: consulta parametrizada\nconst { Pool } = require('pg');\nconst pool = new Pool();\n\napp.post('/login', async (req, res) => {\n  const { username, password } = req.body;\n  \n  // Los signos $1 y $2 son marcadores de posición\n  const query = 'SELECT * FROM users WHERE username = $1 AND password = $2';\n  const values = [username, password];\n  \n  try {\n    const result = await pool.query(query, values);\n    // procesar el resultado...\n  } catch (error) {\n    console.error('Error en la consulta:', error);\n  }\n});

La librería escapa los valores automáticamente. Incluso si un atacante pasa admin' --, se interpretará como una cadena normal, no como un comando SQL.

Medidas de protección adicionales

\n
• Validación en el servidor: verifica el tipo y la longitud de los datos de entrada. Si se espera un email, asegúrate de que realmente sea un email.
\n
• Principio de mínimo privilegio: no uses el usuario root de la base de datos en la aplicación. Crea un usuario separado con permisos solo sobre las tablas necesarias.
\n
• Librerías ORM: utiliza Prisma, Sequelize o TypeORM. Automatizan la parametrización, pero no olvides que también se puede escribir código inseguro con ellas (por ejemplo, usando sequelize.query con concatenación).
\n

XSS (Cross-Site Scripting): Cuando tu sitio se ataca a sí mismo

XSS es un ataque en el que un atacante inyecta código JavaScript malicioso en una página, el c