Skip to content
NeuralSkills
Revision de Codigo

Revision de Seguridad de Codigo

Revision profunda de seguridad: inyeccion, XSS, CSRF, bypass de autenticacion y exposicion de datos sensibles.

Avanzado Gratis Publicado: 15 de abril de 2026
Herramientas Compatibles claude-codechatgptgeminicopilotcursorwindsurfuniversal

El Problema

Las vulnerabilidades de seguridad se esconden a plena vista. Un desarrollador escribe innerHTML = userInput sin pensarlo dos veces. Un endpoint API omite verificaciones de autorizacion porque “es interno.” Un secreto JWT se commitea en un archivo de configuracion. Las revisiones estandar de codigo detectan problemas de estilo pero sistematicamente pasan por alto estos vectores de ataque porque los revisores carecen de un modelo mental enfocado en seguridad.

El Prompt

Realiza una revision de codigo enfocada en seguridad. Actua como un pentester revisando codigo fuente antes de una auditoria.

LENGUAJE/FRAMEWORK: [ej. TypeScript/Next.js, Python/Django, Java/Spring]
DEPLOYMENT: [ej. API publica, dashboard interno, backend movil]

CODIGO:
[pegar codigo aqui]

Analiza contra el OWASP Top 10 (2021) mas estos vectores adicionales:

1. **Inyeccion** (SQL, NoSQL, comandos OS, LDAP)
   - Se concatena entrada del usuario en queries o comandos?
   - Se usan queries parametrizadas consistentemente?

2. **Autenticacion Rota**
   - Se hashean passwords con bcrypt/argon2 (no MD5/SHA)?
   - El manejo de sesiones es seguro (httpOnly, secure, sameSite)?
   - Hay rate limits en endpoints de login/reset?

3. **Exposicion de Datos Sensibles**
   - Hay secrets hardcodeados o logueados?
   - Los mensajes de error filtran stack traces o rutas internas?

4. **XSS (Cross-Site Scripting)**
   - Se sanitiza la entrada del usuario antes de renderizar en HTML?
   - Se usa dangerouslySetInnerHTML / v-html con datos no confiables?
   - Estan configurados los headers CSP?

5. **CSRF (Cross-Site Request Forgery)**
   - Los endpoints que cambian estado estan protegidos con tokens CSRF?

6. **Control de Acceso Roto**
   - Los usuarios pueden acceder a recursos de otros usuarios (IDOR)?
   - Los endpoints admin estan protegidos mas alla de ocultar la UI?

7. **Configuracion de Seguridad Incorrecta**
   - Hay modos debug, credenciales por defecto o errores verbosos expuestos?
   - Los headers CORS son demasiado permisivos (origin: *)?

8. **Supply Chain**
   - Las dependencias estan pinneadas a versiones exactas?

Para cada vulnerabilidad, proporciona:
- **CWE ID**: Identificador Common Weakness Enumeration
- **Severidad**: Critico / Alto / Medio / Bajo
- **Vector de Ataque**: Como un atacante lo explotaria
- **Prueba de Concepto**: Ejemplo de entrada maliciosa
- **Fix**: Codigo seguro de reemplazo

Ejemplo de Salida

## Revision de Seguridad: 4 vulnerabilidades encontradas

### CRITICO — CWE-89: SQL Injection
Ubicacion: src/api/users.ts:47
Codigo: `db.query("SELECT * FROM users WHERE email = '" + req.body.email + "'")`
Vector: Atacante envia email: `' OR '1'='1' --`
Fix:
  db.query("SELECT * FROM users WHERE email = $1", [req.body.email])

### ALTO — CWE-79: Stored XSS
Ubicacion: src/components/Comment.tsx:12
Fix: Usar DOMPurify: `<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(comment.body) }} />`

Cuando Usar

Ejecutar en cada pull request que toque autenticacion, autorizacion o manejo de entrada del usuario. Esencial antes de deployar cualquier servicio publico o procesar pagos. El costo de encontrar una vulnerabilidad antes de produccion es ordenes de magnitud menor que despues.

Tips Pro

  • Dar contexto de deployment — “API publica con 50k usuarios” activa evaluaciones de severidad diferentes que “herramienta admin interna detras de VPN.”
  • Encadenar con auditoria de dependencias — despues del codigo, preguntar “Ahora audita el package.json para CVEs conocidos.”
  • Pedir modelo de amenazas — “Basado en este codigo, cuales son los 3 principales escenarios de ataque?”
  • Probar los fixes — “Genera comandos curl para verificar que cada vulnerabilidad esta parchada.”