Estoy aprendiendo NextJS y estoy tratando de determinar cómo diseñar mi proyecto con una arquitectura limpia que también sea segura. Sin embargo, no estoy seguro de dónde almacenar el código que contiene datos potencialmente confidenciales (es decir, conexiones a bases de datos, acceso al sistema de archivos, etc.). He leído los documentos, pero todavía no estoy seguro de este problema.
En el diseño de mi proyecto, tengo 2 directorios que se relacionan con este problema: un /lib de nivel superior que agregué y el directorio /pages/api que viene incluido en cada proyecto de NextJS.
Según tengo entendido /pages/api NUNCA ve el lado del cliente y, por lo tanto, es seguro para el código confidencial. Solo debe usarse como un lugar para realizar operaciones de publicación, parche, eliminación, etc. Un ejemplo de dónde se usa /pages/api sería cuando realiza una solicitud de publicación al servidor desde un formulario. Puede llamar a una API desde esta ruta desde CUALQUIER LUGAR, por ejemplo: un componente de formulario, la carpeta /lib , una página en /pages , una API externa de terceros, donde sea.
Por otro lado, el directorio /lib de nivel superior es un lugar para el código repetitivo, que lleva a cabo operaciones tediosas, como clasificar publicaciones de blog en orden alfabético, hacer cálculos matemáticos, etc. Eso no es necesariamente "secreto" o confidencial, solo largo y código molesto. El directorio /lib SIEMPRE será visto por el lado del cliente, incluso si es un código al que solo llama un método del lado del servidor, como getStaticProps() .
En resumen, cualquier cosa remotamente sensible siempre debe hacerse como una solicitud de publicación, parche, colocación, etc. en el directorio /pages/api , y cualquier código largo/tedioso que no sea sensible debe refactorizarse en el directorio /lib .
¿Tengo esto bien?
Puede hacer cosas confidenciales en rutas api, getServerSideProps , getStaticProps . El cliente no verá nada de su código en /lib a menos que su página realmente importe código desde allí.
Como estaba hablando de conexiones de base de datos, es muy poco probable que pueda conectarse a su base de datos desde el navegador por accidente. Casi ninguna de las bibliotecas utilizadas para conectarse a db no funcionará desde el navegador y solo puede acceder a las variables env que comienzan con NEXT_PUBLIC_ en el cliente.
También debe tener en cuenta que cada archivo en /api será una ruta api, por lo que debe colocar sus archivos auxiliares dentro de /lib en lugar de /api . Si los coloca en /api , podría generar vulnerabilidades de seguridad, ya que cualquiera puede activar la función de exportación predeterminada de los archivos en /api .
Si por alguna razón necesita estar absolutamente seguro de que algún código no está incluido en los archivos que los clientes cargarán, incluso si lo importa accidentalmente, puede hacerlo con la configuración personalizada del paquete web. Tenga en cuenta que solo buscaría en esta opción si el código en sí mismo es muy sensible. Como si alguien pudiera leer el código tendría consecuencias. No hablando de código que hace consultas de base de datos ni nada por el estilo, incluso si los importó por accidente a los paquetes de clientes, no representaría ninguna amenaza ya que el cliente no puede conectarse a su base de datos.
/pages/api y lib deberían ser lo suficientemente seguros. Next.js no expone estos archivos. Next.js expone los archivos en su carpeta public . Lo que has dicho sobre la lib es correcto. Es solo una carpeta que se puede usar para albergar funciones auxiliares que puede reutilizar dentro de su código.
getStaticProps solo se ejecuta en el lado del servidor. Nunca se ejecutará en el lado del cliente. Ni siquiera se incluirá en el paquete JS para el navegador. Eso significa que puede escribir código como consultas directas a la base de datos sin que se envíen al navegador. Puede realizar sus llamadas de forma segura con esta función.
Hay una herramienta que puede usar para validar ese código en getStaticProps solo se ejecuta en el lado del servidor y nunca se expone en el lado del cliente. Enlace a la herramienta: https://next-code-elimination.vercel.app/
He usado /lib de la misma manera que pretendes en varios proyectos de Next y no he tenido ningún problema. Como han mencionado otros, si está generando todo en el lado del servidor con getStaticProps , debería estar bien.
Una cosa con la que me he encontrado es que el cliente y el servidor no están sincronizados entre el cliente real y el servidor (especialmente con iFrame o datos que se manipulan después de una búsqueda). Eso no causa problemas de seguridad, pero es algo en lo que hay que pensar desde el punto de vista arquitectónico. A continuación, expone su enrutador si necesita sincronizar los efectos con los cambios de URL.