# Auditoria De Seguridad

> Auditoria de seguridad ofensiva y defensiva de tu app Next.js + Supabase. Piensa como ATACANTE: intenta romper los candados (secretos expuestos, RLS debil, IDOR/escalacion de privilegios, headers faltantes, inyeccion XSS/SQLi/SSRF, endpoints de prueba olvidados, webhooks sin auth, dependencias vulnerables, inyeccion de prompts en agentes IA), caza lo que se escapo, y lo ARREGLA en un loop caza-ar…

- **Type:** Skill
- **Install:** `agentstack add skill-lalakinskywalker-bluntag-claude-skills-auditoria-de-seguridad`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [LalakinSkywalker](https://agentstack.voostack.com/s/lalakinskywalker)
- **Installs:** 0
- **Category:** [Databases](https://agentstack.voostack.com/c/databases)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [LalakinSkywalker](https://github.com/LalakinSkywalker)
- **Source:** https://github.com/LalakinSkywalker/bluntag-claude-skills/tree/master/.claude/skills/auditoria-de-seguridad

## Install

```sh
agentstack add skill-lalakinskywalker-bluntag-claude-skills-auditoria-de-seguridad
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Auditoria de seguridad — El cazador adversario

> "La app funciona, respeta la configuracion, va rapida y se ve bien. Aun asi, una tabla puede tener una policy `USING(true)` que deja a cualquiera con la llave publica (que esta en el HTML) leer los datos de todos los usuarios. Nadie lo vio porque la app funciona. Esa es la clase de hueco que esta skill caza — pensando como el atacante, no como el usuario."

Esta skill es el complemento ofensivo de `validacion-visual`: aquella prueba que la app **funciona**; ésta intenta **romperla**. Recorre 7 dimensiones de ataque, asigna severidad a cada hallazgo, y arregla en un bucle caza-arregla-revalida.

---

## Las 7 dimensiones

### D1 — Secretos y exposición
¿Hay credenciales filtradas en el código, en el bundle que ve el navegador, o en git?
- Grep del repo por patrones de secreto: `eyJ` (JWT), `sk-`, `service_role`, `SECRET`, `PRIVATE_KEY`, `password\s*=`, `BEGIN.*PRIVATE KEY`.
- Confirmar que `.env.local` / `.env*` están en `.gitignore` y nunca se commitearon (`git log --all -- .env*`).
- **Llave maestra en el cliente:** grep de `SUPABASE_SERVICE_ROLE_KEY` o `createAdminClient` en archivos `'use client'` → **CRÍTICO** si aparece.
- **`NEXT_PUBLIC_*` que filtra:** solo deben ser públicas la URL de Supabase, la anon key y sitekeys de captcha. Cualquier otro secreto con ese prefijo se filtra al navegador.
- Buscar secretos en el bundle de producción (`.next/static/**/*.js` y el HTML servido). La anon key es pública por diseño; cualquier OTRO secreto = CRÍTICO.

### D2 — Base de datos / Supabase (RLS, grants, funciones)
- Los advisors de seguridad de Supabase → **0 errores** (los warnings se evalúan caso a caso).
- RLS habilitado en TODAS las tablas públicas:
  ```sql
  SELECT relname FROM pg_class WHERE relnamespace='public'::regnamespace
    AND relkind='r' AND relrowsecurity=false;  -- debe estar vacío
  ```
- **Ninguna policy `USING(true)` / `WITH CHECK(true)`** sin justificación explícita:
  ```sql
  SELECT tablename, policyname, cmd, qual, with_check FROM pg_policies
    WHERE schemaname='public' AND (qual='true' OR with_check='true');
  ```
- Funciones `SECURITY DEFINER` invocables por anon/authenticated sin justificación → revisar `REVOKE`.
- Funciones con `search_path` mutable (riesgo de schema hijack).
- Tablas server-only con `REVOKE ALL FROM anon, authenticated`; buckets de Storage privados salvo justificación.

### D3 — Control de acceso ofensivo (IDOR, escalación, bypass)
Con dos usuarios de prueba A y B:
- **IDOR:** B intenta acceder a recursos de A por ID directo en URL y en cada API (`GET/PATCH/DELETE /recurso/[id_de_A]`). Debe dar 403/404, nunca el recurso.
- **Bypass de middleware:** pegar URLs protegidas sin sesión; confirmar que la protección es **server-side**, no solo un guard de cliente. Probar también las server actions y route handlers directamente.
- **Escalación de privilegios:** un usuario normal intenta acciones de admin (endpoints, server actions, paneles `/admin/*`). Manipular el rol en el cliente y confirmar que el server lo re-valida.
- **Manipulación de sesión:** alterar la cookie/JWT, usar uno expirado, reusar el de otro usuario.
- **Multi-tenant:** si hay `organization_id`, cruzar tenants.

### D4 — Headers de seguridad y CSP
`curl -I` contra producción + revisar `next.config`:
- Presencia y valor de `Strict-Transport-Security`, `X-Frame-Options` (o `frame-ancestors`), `X-Content-Type-Options: nosniff`, `Referrer-Policy`, `Permissions-Policy`, `Content-Security-Policy`.
- CSP: `object-src 'none'`, `frame-ancestors`, `base-uri 'self'`. (Next.js suele requerir `unsafe-inline`/`unsafe-eval` para hidratar — documentarlo como aceptado, no como bug.)
- Cookies de auth con `Secure` + `HttpOnly` + `SameSite`; HTTPS forzado.

### D5 — Inyección y validación de entrada
- **XSS:** grep de `dangerouslySetInnerHTML`, `innerHTML`, render de input sin escapar. Probar payloads ``, `">` en campos y parámetros de URL.
- **SQLi:** PostgREST parametriza por defecto; el riesgo real es SQL crudo (`rpc` mal construido, interpolación de strings en queries). Grep de concatenación en queries.
- **SSRF:** endpoints que hacen `fetch` a una URL derivada de input del usuario (proxies de imagen, webhooks). Verificar allowlist de hosts.
- **Path traversal** en Storage / manejo de archivos (`../`, paths absolutos).
- **Mass assignment:** server actions que hacen `update(body)` con todo el body sin allowlist → un atacante setea `role: 'admin'` o un `user_id` ajeno.

### D6 — Endpoints públicos, webhooks y supply chain
- **Endpoints de prueba olvidados:** grep de `/api/public/dev-*`, `/api/debug`, `/api/test`, `dev-magic-session`. (Las skills de QA crean endpoints temporales; confirmar que se borraron.) Probar en producción.
- **Webhooks:** todos los `/api/webhooks/*` deben verificar origen (HMAC, signature, secret-per-request). Webhook sin secret → debe dar 401/400.
- **Rate limiting:** login/signup/forgot-password y endpoints con LLM deben limitar intentos (fuerza bruta + abuso de tokens). Ráfaga → 429 o captcha.
- **Métodos HTTP:** endpoints que solo aceptan POST rechazan GET/PUT/DELETE (405).
- **CORS:** sin `Access-Control-Allow-Origin: *` en endpoints con datos.
- **Supply chain:** `npm audit --omit=dev` → revisar críticas/altas. Lockfile commiteado.

### D7 — Seguridad de IA (solo si el proyecto tiene agente/LLM)
Auto-detección: si hay un asistente/chat con LLM, activar; si no, omitir y aclararlo.
- **Prompt injection:** "ignora tus instrucciones", pedir que revele su system prompt o su stack técnico.
- **Guardrails:** confirmar que el asistente rechaza usos fuera de su función.
- **Exfiltración:** intentar que devuelva datos de otros usuarios vía su herramienta de búsqueda o tools.
- **Sanitizer de salida:** que filtre datos sensibles antes de mostrarlos.
- **Límite de gasto:** rate limit del chat para que nadie drene tu presupuesto de tokens.

---

## Triage por severidad (esto define qué bloquea la publicación)

| Severidad | Definición | Efecto |
|---|---|---|
| **Crítico** | Explotable hoy, expone datos/credenciales o da acceso no autorizado (secret en cliente, IDOR, RLS off sobre datos sensibles, endpoint dev en prod) | **BLOQUEA la publicación.** |
| **Alto** | Explotable con esfuerzo, o defensa importante ausente (sin CSP, webhook sin auth) | Bloquea entrega/lanzamiento. Se arregla. |
| **Medio** | Riesgo real pero acotado | No bloquea; se arregla si es barato. |
| **Bajo** | Higiene / defensa en profundidad | Recomendación documentada. |

---

## Autonomía: se pausa por IMPACTO, no por dificultad técnica

**Arreglar al momento (reversible con git):** código, headers, CSP, validaciones, guards, sanitización, allowlists, RLS/policies/grants faltantes (verificando que no se deje fuera ningún acceso legítimo), borrar endpoints de prueba, `npm audit fix` sin breaking.

**Pausar y preguntar (decisión de negocio):** rotar una credencial (puede tumbar una integración viva — el *cuándo* lo decide el dueño), tocar datos reales de producción, un cambio que podría dejar fuera a usuarios reales, algo con costo o irreversible, o un crítico que requiere rediseño.

**Modulación por tráfico:** app sin usuarios → autonomía máxima. App con clientes reales → más cuidado con lo que toca acceso/datos/sesiones; ante la duda, verificar antes de cerrar.

---

## El flujo

1. **Mapear la superficie de ataque:** rutas, API routes, webhooks, server actions, páginas admin, tablas, si hay agente IA (activa D7), si hay pagos. Detectar si la app tiene usuarios reales en producción (modula la autonomía).
2. **Setup** (si hay auth): crear dos usuarios de prueba A y B; borrarlos al final.
3. **Ejecutar las 7 dimensiones** en orden. Cada hallazgo: severidad + evidencia + causa raíz.
4. **Loop caza-arregla-revalida:** arreglar lo de bajo impacto al momento (y re-probar el vector); pausar lo que es decisión de negocio. Un crítico sin resolver bloquea.
5. **Limpieza OBLIGATORIA:** borrar usuarios de prueba, registros y payloads de prueba (NUNCA dejar un `` de prueba persistido en la base), endpoints temporales; cerrar el navegador.
6. **Reporte + autorización:** resumen por severidad (encontrados / arreglados / pausados). El push/deploy SIEMPRE lo autoriza el dueño.

---

## Reglas duras

1. **Scope estrictamente defensivo:** solo TUS apps. Nunca targets externos.
2. **Mentalidad adversaria real** (intentar romper, no marcar checkboxes) pero **sin causar daño** (no DoS real, no borrar datos, payloads inertes).
3. **Se pausa por impacto de negocio, no por dificultad técnica.**
4. **Un crítico bloquea la publicación.** Sin excepción.
5. **Cada hallazgo lleva severidad** — sin severidad no hay triage.
6. **Todo cambio de RLS se re-valida** contra los flujos reales, para confirmar que no rompió acceso legítimo.
7. **NUNCA dejar payloads de prueba persistidos** en la base o el Storage.
8. **Secretos jamás al chat, logs o screenshots.** Los scripts leen `.env.local` y no imprimen secretos.
9. **El push/deploy final SIEMPRE lo autoriza el dueño.**
10. **Si una dimensión no aplica** (sin auth, sin IA, sin pagos), aclararlo — no saltarla en silencio.

---

## Anti-patrones (prohibidos)

- "Corrí el advisor y dio 0, listo." → El advisor es solo D2. Faltan IDOR, headers, inyección, endpoints, supply chain, IA.
- "Pausé el fix porque era complejo." → Se pausa por consecuencia de negocio, no por dificultad.
- "Arreglé la policy RLS y seguí sin probar." → Todo cambio de RLS se re-valida contra los flujos reales.
- "Dejé el payload `` de prueba en la base."
- "Encontré un crítico pero el resto estaba bien, aprobé." → Un crítico sin resolver BLOQUEA.
- "La app no tiene pagos, así que omití todo." → Solo se omite la dimensión que no aplica; las demás corren.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [LalakinSkywalker](https://github.com/LalakinSkywalker)
- **Source:** [LalakinSkywalker/bluntag-claude-skills](https://github.com/LalakinSkywalker/bluntag-claude-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** yes
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** yes
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-lalakinskywalker-bluntag-claude-skills-auditoria-de-seguridad
- Seller: https://agentstack.voostack.com/s/lalakinskywalker
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.