Seguridad de aplicaciones TypeScript: top 10 vulnerabilidades para principiantes

Seguridad de aplicaciones TypeScript: top 10 vulnerabilidades para principiantes

TypeScript es una extensión de JavaScript que añade tipado estático, pero no protege contra vulnerabilidades web clásicas. Los desarrolladores principiantes a menudo confían en el rigor de los tipos, olvidando la seguridad a nivel de lógica y datos. En este artículo analizaremos las 10 vulnerabilidades más comunes en aplicaciones TypeScript con ejemplos de código y métodos de protección.

1. XSS (Cross-Site Scripting) mediante dangerouslySetInnerHTML

Uno de los problemas más frecuentes es la inserción de HTML de usuario sin sanitización. En TypeScript esto suele ocurrir al trabajar con React o Angular.

// ❌ Código vulnerable\nfunction UserComment({ comment }: { comment: string }) {\n  return <div dangerouslySetInnerHTML={{ __html: comment }} />;\n}\n\n// ✅ Versión segura\nimport DOMPurify from 'dompurify';\n\nfunction SafeComment({ comment }: { comment: string }) {\n  const sanitized = DOMPurify.sanitize(comment);\n  return <div dangerouslySetInnerHTML={{ __html: sanitized }} />;\n}

2. Inyecciones SQL mediante consultas de cadena

TypeScript no protege contra inyecciones SQL si se utilizan cadenas sin procesar. Utilice siempre consultas parametrizadas.

// ❌ Peligroso\nconst query = `SELECT * FROM users WHERE email = '${userEmail}'`;\n\n// ✅ Seguro (ejemplo con Prisma)\nconst user = await prisma.user.findUnique({\n  where: { email: userEmail }\n});

3. Almacenamiento inseguro de secretos en el código

Las claves de API, tokens y contraseñas no deben estar en el código fuente. TypeScript se compila a JavaScript y todas las cadenas siguen siendo legibles.

// ❌ Nunca haga esto\nconst API_KEY = 'sk-1234567890abcdef';\n\n// ✅ Use variables de entorno\nconst API_KEY = process.env.API_KEY;\nif (!API_KEY) throw new Error('API_KEY is missing');

4. Inyecciones NoSQL (MongoDB)

Al trabajar con MongoDB mediante Mongoose o el driver, se puede pasar accidentalmente un objeto de consulta que manipule la lógica.

// ❌ Código vulnerable\napp.post('/login', async (req, res) => {\n  const user = await User.findOne({ \n    email: req.body.email, \n    password: req.body.password \n  });\n});\n\n// ✅ Versión segura\napp.post('/login', async (req: Request, res: Response) => {\n  const { email, password } = req.body;\n  if (typeof email !== 'string' || typeof password !== 'string') {\n    return res.status(400).send('Invalid input');\n  }\n  const user = await User.findOne({ email, password });\n});

5. CSRF (Cross-Site Request Forgery)

Si su aplicación utiliza autenticación por cookies, un atacante puede realizar acciones en nombre del usuario.

// ❌ Sin protección\napp.post('/transfer', (req, res) => {\n  // Realiza la transferencia sin verificar el origen\n});\n\n// ✅ Protección mediante token CSRF (ejemplo con csurf)\nimport csrf from 'csurf';\nconst csrfProtection = csrf({ cookie: true });\napp.post('/transfer', csrfProtection, (req, res) => {\n  // Ejecución segura\n});

6. Contaminación de prototipos (Prototype Pollution)

Al fusionar objetos sin verificación, se pueden sobrescribir propiedades del prototipo, lo que genera vulnerabilidades.

// ❌ Peligroso\nfunction merge(target: any, source: any) {\n  for (const key in source) {\n    target[key] = source[key];\n  }\n}\n\n// ✅ Seguro\nfunction safeMerge(target: Record<string, any>, source: Record<string, any>) {\n  for (const key in source) {\n    if (Object.prototype.hasOwnProperty.call(source, key)) {\n      target[key] = source[key];\n    }\n  }\n}

7. Fuga de información mediante errores

Los stack traces y detalles de la base de datos no deben mostrarse al usuario. TypeScript puede dar una falsa sensación de seguridad debido al tipado estricto.

// ❌ Malo\napp.use((err, req, res, next) => {\n  res.status(500).json({ error: err.m