// guía de seguridad
Seguridad para apps hechas con Claude Code
Claude Code es un CLI que escribe código directo en tu repo. Es muy capaz pero también muy autónomo: puede leer archivos, ejecutar comandos y commitear cambios. Los patrones de seguridad acá no son sobre "qué genera el modelo" sino sobre "cómo configurás los guardrails".
// contexto del stack
Contexto de Claude Code
Claude Code puede crear, modificar y borrar archivos. Eso lo hace poderoso para refactors grandes, pero también significa que un comando mal interpretado puede tocar archivos sensibles. Los hooks y los permission prompts son tu defensa principal.
// hallazgos frecuentes
Vulnerabilidades más comunes en Claude Code
01 Permisos amplios que permiten leer/modificar archivos sensibles
Por default, Claude Code pide permiso para cada acción que puede afectar tu sistema. Si vas aprobando "yes to all" rápido, podés autorizar lecturas de `.env`, modificaciones de `.git/config`, ejecuciones de scripts no revisados.
→ cómo arreglarlo
Configurá restricciones en `~/.claude/settings.json` que bloqueen acceso a archivos sensibles. Por ejemplo, denegar Read en `.env*`, `.aws/`, `~/.ssh/`. Mantené el permission prompt activo para acciones destructivas.
02 Commits autorizados sin code review
Claude Code puede ejecutar `git commit` si vos lo autorizás. Si confiás en sus commits sin leer los diffs, podés terminar con código que parece OK pero introduce bugs sutiles de seguridad.
→ cómo arreglarlo
Mantené `--no-verify` deshabilitado (default). Configurá pre-commit hooks (lint, type check, tests). Idealmente: requerí PR review antes de mergear, no commits directos a main.
03 Variables de entorno expuestas en logs
Cuando Claude Code ejecuta un comando que loggea env vars (ej. `env` para debugging), pueden quedar en tu historial de bash o en logs si los redirigís.
→ cómo arreglarlo
Evitá imprimir env vars directamente. Si necesitás verificar que existe una clave, usá `[ -n "$SECRET" ] && echo "set"` en lugar de imprimir el valor.
04 Generación de tests insuficientes para casos de seguridad
Como otros asistentes, Claude Code genera tests "happy path" por default. Tests de autorización ("el user A no puede acceder a recursos del user B") requieren pedirlos explícitamente.
→ cómo arreglarlo
Por cada endpoint con auth, pedí tests negativos por nombre. "Generá tests donde el caller no esté autenticado y donde esté autenticado pero sin permisos para ese recurso".
05 Configuración de skills y agentes con permisos amplios
Skills y subagentes pueden recibir permisos diferentes al main agent. Un skill mal configurado podría tener Write access cuando solo necesita Read.
→ cómo arreglarlo
Audita los skills instalados con `claude skills list`. Para cada uno, revisá los permisos definidos. Aplicá el principio de least privilege: solo los permisos que el skill realmente necesita.
// checklist pre-launch
Checklist pre-launch para Claude Code
- Configurar denylist en `~/.claude/settings.json` para `.env*`, `.aws/`, `~/.ssh/`
- Mantener permission prompts activos para acciones destructivas
- No usar `--no-verify` en commits (mantiene pre-commit hooks)
- Code review humano de cada PR generado
- Pre-commit con gitleaks/trufflehog para detectar secrets
- Pedir explícitamente tests de autorización (no solo happy path)
- Auditar skills y subagentes instalados
- Headers de seguridad configurados en el hosting
- Si usás Supabase: RLS en todas las tablas
- Auditar con VibeAuditt antes del launch
// lectura relacionada
Posts relacionados
// escaneá ahora
Audita tu app Claude Code gratis
VibeAuditt detecta automáticamente los errores de este checklist en menos de un minuto. Sin tarjeta, sin instalación.