# Seguridad básica para quien crea apps

> Cada Server Action y cada Route Handler de tu app es una puerta pública en internet, por lo que tu servidor debe comprobar quién ha entrado, validar cada dato recibido con un esquema, usar consultas parametrizadas, aplicar límites de uso y no usar jamás `NEXT_PUBLIC_` en secretos.

## Analogía

Ocultar un botón en una página web es como poner un cartel de «Solo personal autorizado» en una puerta trasera sin llave. La seguridad real consiste en echar la llave a la puerta y comprobar la acreditación de quien intente abrirla, aunque venga directo desde el callejón.

## Cómo funciona

En Next.js, cualquier Server Action o Route Handler de tu backend puede llamarse directamente desde internet, no solo pulsando el formulario de tu frontend. Por eso cada puerta del servidor sigue siempre el mismo orden de tres pasos antes de tocar la database: (1) comprobar la sesión de Better Auth y confirmar que esa persona tiene permiso sobre ese dato, (2) validar los datos recibidos con un **esquema** estricto (como Zod: tipo, longitud y formato), y (3) usar **consultas parametrizadas** para que el texto escrito se trate siempre como dato y nunca como una orden para la base de datos.

Mantén cada secret en el servidor. Cualquier env-var cuyo nombre empiece por `NEXT_PUBLIC_` se envía al navegador de todas las personas que visitan tu web; por tanto, una api-key, la dirección de la base de datos o un secreto de acceso jamás deben llevar `NEXT_PUBLIC_`. Además, el desarrollo en tu equipo usa siempre su propia rama de desarrollo en Neon, nunca la base de datos de production.

Protege las puertas sensibles o que consumen saldo con un rate-limit: pon un tope por minuto a los intentos de inicio de sesión, al envío de formularios y a las llamadas a un model de IA. Cuando tu app envíe texto a un proveedor de IA, evita incluir datos personales salvo que la función lo requiera de verdad, y valida y escapa siempre la respuesta del modelo antes de mostrarla.

Por último, tu agente añade **cabeceras de seguridad** estrictas (incluida una política de seguridad de contenidos, **CSP**, y reglas **CORS** ajustadas) para que el navegador bloquee scripts inyectados e impida que otras webs suplanten a tu app. Puedes repasar la lista completa en la página [Calidad y seguridad](@quality).

## En tu proyecto

Siempre que tu agente escribe código que toca inicios de sesión, formularios, la base de datos o secretos, aplica la skill `security-and-hardening`. Antes de fusionar un pull request, puedes pedirle una revisión de seguridad de todas las rutas y variables de entorno.

## Copia para tu agente

```text
Haz una revisión de seguridad de mi proyecto usando la skill security-and-hardening: comprueba que cada Server Action y cada Route Handler verifica la sesión y valida los datos con un esquema, que todas las consultas son parametrizadas, que hay límites de uso y que ningún secreto lleva NEXT_PUBLIC_.
```

---
Fuente: [Agentic Makers](https://agenticmakers.app/es/aprende/seguridad-basica) · Licencia: CC BY 4.0