Security audit
Encuentra vulnerabilidades que un atacante pueda explotar de verdad y demuéstralo con la ruta de ataque. Un informe con veinte "posibles riesgos" sin verificar hace perder más tiempo del que ahorra: prima la precisión sobre el volumen.
Esta skill es para auditar código propio o autorizado. Las pruebas de concepto se describen o se limitan a peticiones mínimas contra un entorno local; nunca se lanzan contra producción ni contra sistemas de terceros.
Modo
Según el argumento:
- Sin argumento → repo completo.
diff [rama-base] → solo cambios: git diff <base>...HEAD más lo no commiteado. Base por defecto: la rama principal (git symbolic-ref refs/remotes/origin/HEAD, o main/master). Audita lo cambiado, pero sigue el flujo hacia el código sin cambios: un cambio puede volver alcanzable un fallo antiguo o quitar una protección.- Una ruta → solo esa carpeta o archivo, más lo que necesites para entender su contexto.
No modifiques código durante la auditoría. Los fixes vienen después y solo los que apruebe el usuario.
1. Reconocimiento
Antes de buscar fallos, entiende qué hay que proteger y por dónde se entra. Resúmelo en pocas líneas al principio del informe.
- Stack: lee
package.json, wrangler.toml/wrangler.jsonc, next.config.* y similares. Lee solo las guías de references/ que apliquen:
- Node/TS, Express, Fastify, APIs →
references/node-api.md
- MongoDB/Mongoose →
references/mongodb.md
- Cloudflare Workers, R2, KV, D1, Durable Objects →
references/cloudflare.md
- React, Next.js, Vite →
references/frontend.md
- Puntos de entrada: rutas HTTP, server actions, handlers
fetch de Workers, webhooks, crons, consumidores de colas, WebSockets, CLIs.
- Autenticación: cómo se identifica al usuario (sesión, JWT, Cloudflare Access, API keys) y dónde se comprueba.
- Activos: datos personales, pagos, secretos, funciones de administración, archivos de usuarios.
- Fronteras de confianza: todo lo que llega del cliente, de webhooks, de colas o de URLs externas es controlable por un atacante.
2. Búsqueda
Recorre las categorías en este orden, de mayor a menor impacto habitual. Las guías de references/ dicen qué buscar en cada stack.
- Autorización: cada operación sobre un recurso comprueba en el servidor que ese usuario puede hacerla sobre ese recurso (IDOR, rutas sin middleware, rutas de admin, roles que vienen del cliente, mass assignment).
- Autenticación y sesiones: verificación de JWT, hash de contraseñas, tokens de reset, cookies, rate limiting en login/OTP/reset.
- Inyección: SQL, NoSQL, comandos, path traversal,
eval/new Function, plantillas, prototype pollution, ReDoS.
- XSS y salida: HTML sin escapar,
dangerouslySetInnerHTML, URLs javascript:, archivos subidos servidos desde el mismo origen.
- SSRF y redirecciones: peticiones salientes o redirecciones a URLs controladas por el usuario.
- Secretos: claves en el código, en variables públicas del bundle, en
wrangler [vars], en logs o en el historial de git.
- Subida y descarga de archivos: tamaño, tipo, nombres y claves de almacenamiento, buckets públicos, URLs firmadas.
- Configuración: CORS, cabeceras de seguridad, modo debug, stack traces en respuestas, caché de respuestas autenticadas.
- Lógica de negocio: precios o importes que vienen del cliente, condiciones de carrera (saldo, stock, cupones), pasos saltables en flujos.
- Dependencias: si hay lockfile,
npm audit --omit=dev (o el equivalente del gestor). Hace una petición de red: envía la lista de dependencias al registro de npm. Si no hay red o el usuario no la quiere, anótalo en "No revisado".
En repos grandes, prioriza los puntos de entrada y las zonas con activos. Es mejor declarar lo que no has cubierto que aparentar una cobertura completa.
3. Verificación
Cada candidato pasa por esto antes de entrar en el informe:
- Origen: ¿qué dato controla el atacante y por dónde entra?
- Camino: sigue ese dato hasta el punto peligroso (query, comando, HTML, fetch, clave de R2…). ¿Hay validación, middleware o escape por el camino? Léelos: no supongas.
- Alcanzable: ¿la ruta está registrada y expuesta? ¿Qué hace falta para llegar: nada, estar logueado, ser admin?
- Impacto: ¿qué consigue exactamente el atacante?
Si se confirma → Confirmada. Si falta una pieza que no puedes comprobar desde el código (configuración de infraestructura, comportamiento de un servicio externo) → Probable, diciendo qué falta. Si no hay camino real → descártalo.
4. Informe
Escríbelo en el chat, no en un archivo del repo: un informe de vulnerabilidades commiteado por error en un repo público es un regalo para un atacante.
Nunca muestres un secreto completo: enmáscaralo (sk_live_…4f2a) e indica que hay que rotarlo. Borrarlo del código no basta, porque sigue en el historial de git.
## Auditoría de seguridad: <repo> (<modo>)
Superficie: <stack, nº de puntos de entrada, cómo se autentica, activos principales>
Resultado: <n> críticas · <n> altas · <n> medias · <n> bajas
### [S1] [CRÍTICA] <título corto>
- Dónde: `ruta/archivo.ts:42`
- Ataque: <qué hace el atacante, paso a paso, en 1-3 líneas>
- Por qué funciona: <el control que falta, con referencia al código>
- Impacto: <qué obtiene>
- Confianza: Confirmada | Probable (<qué falta por comprobar>)
- Fix: <cambio mínimo; diff corto si ayuda>
### [S2] ...
Revisado sin hallazgos: <categorías y zonas revisadas>
No revisado: <lo que quedó fuera y por qué>
Gravedad:
- Crítica: explotable en remoto sin autenticación, o por cualquier usuario, con robo de datos, dinero o control de la cuenta o del sistema.
- Alta: requiere una cuenta normal, o tiene un impacto grave pero acotado.
- Media: requiere condiciones específicas o interacción de la víctima, o expone información sensible menor.
- Baja: endurecimiento y buenas prácticas sin explotación directa.
Ordena por gravedad. No infles: una cabecera ausente no es Alta.
5. Fixes
Al final del informe, pregunta qué hallazgos corregir (por id: S1, S3). Para cada fix aprobado:
- Cambio mínimo que cierra el ataque, siguiendo las convenciones del repo.
- Si hay tests, añade uno que reproduzca el ataque y compruebe que ahora falla.
- Si el fix cambia comportamiento visible (usuarios que dejarán de poder hacer algo, datos migrados), avisa antes de aplicarlo.
- Los secretos expuestos requieren acción del usuario (rotar la clave en el proveedor): dilo explícitamente, porque el código no puede hacerlo.
1---2name: security-audit-23description: Auditoría de seguridad de un repositorio completo o de los cambios de una rama. Busca vulnerabilidades explotables (autorización, inyección, XSS, SSRF, secretos, subidas de archivos, configuración, lógica de negocio, dependencias), verifica cada hallazgo trazando la ruta de ataque y entrega un informe por gravedad con fixes propuestos. Guías específicas para Node/TS, MongoDB, Cloudflare Workers/R2 y React/Next. Se invoca con /security-audit, /security-audit diff [rama-base] o /security-audit <ruta>.4---56# Security audit78Encuentra vulnerabilidades que un atacante pueda explotar de verdad y demuéstralo con la ruta de ataque. Un informe con veinte "posibles riesgos" sin verificar hace perder más tiempo del que ahorra: prima la precisión sobre el volumen.910Esta skill es para auditar código propio o autorizado. Las pruebas de concepto se describen o se limitan a peticiones mínimas contra un entorno local; nunca se lanzan contra producción ni contra sistemas de terceros.1112## Modo1314Según el argumento:1516- Sin argumento → **repo completo**.17- `diff [rama-base]` → **solo cambios**: `git diff <base>...HEAD` más lo no commiteado. Base por defecto: la rama principal (`git symbolic-ref refs/remotes/origin/HEAD`, o `main`/`master`). Audita lo cambiado, pero sigue el flujo hacia el código sin cambios: un cambio puede volver alcanzable un fallo antiguo o quitar una protección.18- Una ruta → solo esa carpeta o archivo, más lo que necesites para entender su contexto.1920No modifiques código durante la auditoría. Los fixes vienen después y solo los que apruebe el usuario.2122## 1. Reconocimiento2324Antes de buscar fallos, entiende qué hay que proteger y por dónde se entra. Resúmelo en pocas líneas al principio del informe.2526- **Stack**: lee `package.json`, `wrangler.toml`/`wrangler.jsonc`, `next.config.*` y similares. Lee **solo** las guías de `references/` que apliquen:27 - Node/TS, Express, Fastify, APIs → `references/node-api.md`28 - MongoDB/Mongoose → `references/mongodb.md`29 - Cloudflare Workers, R2, KV, D1, Durable Objects → `references/cloudflare.md`30 - React, Next.js, Vite → `references/frontend.md`31- **Puntos de entrada**: rutas HTTP, server actions, handlers `fetch` de Workers, webhooks, crons, consumidores de colas, WebSockets, CLIs.32- **Autenticación**: cómo se identifica al usuario (sesión, JWT, Cloudflare Access, API keys) y dónde se comprueba.33- **Activos**: datos personales, pagos, secretos, funciones de administración, archivos de usuarios.34- **Fronteras de confianza**: todo lo que llega del cliente, de webhooks, de colas o de URLs externas es controlable por un atacante.3536## 2. Búsqueda3738Recorre las categorías en este orden, de mayor a menor impacto habitual. Las guías de `references/` dicen qué buscar en cada stack.39401. **Autorización**: cada operación sobre un recurso comprueba en el servidor que *ese* usuario puede hacerla sobre *ese* recurso (IDOR, rutas sin middleware, rutas de admin, roles que vienen del cliente, mass assignment).412. **Autenticación y sesiones**: verificación de JWT, hash de contraseñas, tokens de reset, cookies, rate limiting en login/OTP/reset.423. **Inyección**: SQL, NoSQL, comandos, path traversal, `eval`/`new Function`, plantillas, prototype pollution, ReDoS.434. **XSS y salida**: HTML sin escapar, `dangerouslySetInnerHTML`, URLs `javascript:`, archivos subidos servidos desde el mismo origen.445. **SSRF y redirecciones**: peticiones salientes o redirecciones a URLs controladas por el usuario.456. **Secretos**: claves en el código, en variables públicas del bundle, en `wrangler [vars]`, en logs o en el historial de git.467. **Subida y descarga de archivos**: tamaño, tipo, nombres y claves de almacenamiento, buckets públicos, URLs firmadas.478. **Configuración**: CORS, cabeceras de seguridad, modo debug, stack traces en respuestas, caché de respuestas autenticadas.489. **Lógica de negocio**: precios o importes que vienen del cliente, condiciones de carrera (saldo, stock, cupones), pasos saltables en flujos.4910. **Dependencias**: si hay lockfile, `npm audit --omit=dev` (o el equivalente del gestor). **Hace una petición de red**: envía la lista de dependencias al registro de npm. Si no hay red o el usuario no la quiere, anótalo en "No revisado".5051En repos grandes, prioriza los puntos de entrada y las zonas con activos. Es mejor declarar lo que no has cubierto que aparentar una cobertura completa.5253## 3. Verificación5455Cada candidato pasa por esto antes de entrar en el informe:56571. **Origen**: ¿qué dato controla el atacante y por dónde entra?582. **Camino**: sigue ese dato hasta el punto peligroso (query, comando, HTML, fetch, clave de R2…). ¿Hay validación, middleware o escape por el camino? Léelos: no supongas.593. **Alcanzable**: ¿la ruta está registrada y expuesta? ¿Qué hace falta para llegar: nada, estar logueado, ser admin?604. **Impacto**: ¿qué consigue exactamente el atacante?6162Si se confirma → `Confirmada`. Si falta una pieza que no puedes comprobar desde el código (configuración de infraestructura, comportamiento de un servicio externo) → `Probable`, diciendo qué falta. Si no hay camino real → descártalo.6364## 4. Informe6566Escríbelo en el chat, no en un archivo del repo: un informe de vulnerabilidades commiteado por error en un repo público es un regalo para un atacante.6768Nunca muestres un secreto completo: enmáscaralo (`sk_live_…4f2a`) e indica que hay que **rotarlo**. Borrarlo del código no basta, porque sigue en el historial de git.6970```71## Auditoría de seguridad: <repo> (<modo>)7273Superficie: <stack, nº de puntos de entrada, cómo se autentica, activos principales>74Resultado: <n> críticas · <n> altas · <n> medias · <n> bajas7576### [S1] [CRÍTICA] <título corto>77- Dónde: `ruta/archivo.ts:42`78- Ataque: <qué hace el atacante, paso a paso, en 1-3 líneas>79- Por qué funciona: <el control que falta, con referencia al código>80- Impacto: <qué obtiene>81- Confianza: Confirmada | Probable (<qué falta por comprobar>)82- Fix: <cambio mínimo; diff corto si ayuda>8384### [S2] ...8586Revisado sin hallazgos: <categorías y zonas revisadas>87No revisado: <lo que quedó fuera y por qué>88```8990Gravedad:9192- **Crítica**: explotable en remoto sin autenticación, o por cualquier usuario, con robo de datos, dinero o control de la cuenta o del sistema.93- **Alta**: requiere una cuenta normal, o tiene un impacto grave pero acotado.94- **Media**: requiere condiciones específicas o interacción de la víctima, o expone información sensible menor.95- **Baja**: endurecimiento y buenas prácticas sin explotación directa.9697Ordena por gravedad. No infles: una cabecera ausente no es Alta.9899## 5. Fixes100101Al final del informe, pregunta qué hallazgos corregir (por id: `S1, S3`). Para cada fix aprobado:102103- Cambio mínimo que cierra el ataque, siguiendo las convenciones del repo.104- Si hay tests, añade uno que reproduzca el ataque y compruebe que ahora falla.105- Si el fix cambia comportamiento visible (usuarios que dejarán de poder hacer algo, datos migrados), avisa antes de aplicarlo.106- Los secretos expuestos requieren acción del usuario (rotar la clave en el proveedor): dilo explícitamente, porque el código no puede hacerlo.
Leksgg