Next.js está diseñado con una mentalidad orientada a la seguridad y trae valores por defecto que protegen tu aplicación sin que tengas que configurarlo todo desde cero. Aquí revisamos cómo los Server Actions, los React Server Components y las variables de entorno impactan la seguridad de tu proyecto, junto con los errores más comunes que cometemos al construir formularios y conexiones a bases de datos.

¿Cómo protege Next.js los endpoints de Server Actions?

Cuando ejecutas un Server Action en producción, Next.js no expone una ruta predecible. En cambio, genera IDs automáticos que rotan cada 14 minutos aproximadamente, dificultando que un atacante automatice la detección de tus endpoints.

En el ejemplo del Expense Tracker, al inspeccionar la pestaña network puedes ver que el formulario funciona contra un endpoint con un identificador dinámico. En los headers aparece información del Next Action, un state tree y validaciones de origen que aseguran que la petición venga de una fuente legítima.

¿Qué es un Server Action en Next.js? Es una función marcada con use server que se ejecuta en el servidor y puede invocarse desde un componente cliente, normalmente a través de un formulario, sin necesidad de crear un endpoint manual.

¿Por qué no debo escribir Server Actions inline dentro de un componente?

JavaScript, React y Next.js te permiten declarar la función de un Server Action directamente dentro del componente. Funciona, pero abre una puerta peligrosa.

Imagina que dentro del componente accedes a un secreto, por ejemplo la URL de conexión a SQL, y luego lo usas dentro del Server Action inline. Lo que ocurre es que JavaScript crea un closure que captura ese valor, y esa información se intercambia entre cliente y servidor durante la ejecución. Sin querer, podrías estar enviando un secreto al navegador.

Next.js da un paso adelante y encripta esta información de forma automática cuando despliegas en Vercel, generando llaves de encriptación sin intervención tuya. Pero si alojas el proyecto en otro servidor o no manejas bien las llaves, ese secreto podría quedar expuesto.

La práctica recomendada es clara:

• Mueve los Server Actions a un archivo dedicado, por ejemplo actions.ts.
• Importa la conexión a la base de datos desde otro archivo separado.
• Pasa al cliente solo el resultado de la función, nunca el closure con secretos.
• Mantén el código mantenible y explícito sobre qué corre en servidor y qué en cliente.

Así evitas que la flexibilidad del lenguaje juegue en tu contra.

¿Cómo funcionan las variables de entorno en Next.js?

Las variables de entorno en Next.js tienen un comportamiento que ayuda a mitigar fugas de información. Por defecto, una variable de entorno no estará disponible en el código de cliente, aunque intentes usarla. Si lo haces, Next.js la dejará como undefined.

Para exponerla al cliente debes anteponer el prefijo NEXT_PUBLIC_. Esa decisión es explícita y obliga a pensar dos veces antes de filtrar un valor sensible.

¿Qué hace el prefijo NEXT_PUBLIC en una variable de entorno? Le indica a Next.js que esa variable puede cargarse en el navegador. Si la usas en código de cliente, su valor se revelará en el bundle, así que nunca pongas secretos detrás de ese prefijo.

¿Qué debo auditar en mis variables de entorno?

Aunque Next.js te protege con este comportamiento por defecto, la responsabilidad final es tuya. Revisa periódicamente:

• Que ninguna variable con NEXT_PUBLIC_ contenga secretos, llaves de API privadas o credenciales de base de datos.
• Que las variables sensibles solo se usen en archivos de servidor o marcados como server-only.
• Que tu equipo entienda la convención antes de agregar nuevas variables al proyecto.

Un framework seguro no sustituye una auditoría proactiva. Es una capa más, no la única.

¿Qué ataques mitiga Next.js cuando lo usas correctamente?

Al separar bien el código de servidor del de cliente, marcar correctamente los Server Actions y respetar las convenciones de variables de entorno, Next.js te ayuda a mitigar varios vectores comunes en aplicaciones web:

• Ataques de code injection gracias a la validación de Server Actions.
• Ataques de XSS por el manejo seguro de los componentes y la serialización.
• Exposición de secretos a través del control estricto de variables de entorno.
• Detección automatizada de endpoints, mitigada por los IDs rotativos.

La flexibilidad de React y Next.js es enorme, y por eso conviene establecer convenciones internas en tu equipo: Server Actions en archivos dedicados, conexiones a base de datos aisladas, y revisiones de código enfocadas en seguridad. ¿Has revisado hoy si alguno de tus Server Actions está cargando secretos por closure?