Aplicaciones Vue y Nuxt más seguras - Por defecto

Rate this content
Bookmark

Como desarrolladores, generalmente tenemos que desarrollar rápido y debido a eso, algunos aspectos de calidad del software como el rendimiento, la accesibilidad o la seguridad pueden verse afectados. Configurar aplicaciones web para protegerlas contra amenazas comunes y hackers es difícil. Y por eso, puedes usar Nuxt Security -> un módulo para Nuxt que te ayudará a construir aplicaciones más seguras sin necesidad de configuración adicional.

En esta charla, te guiaré a través de los conceptos de seguridad en las aplicaciones web modernas y OWASP para ayudarte a construir aplicaciones Vue y Nuxt más seguras.

Jakub Andrzejewski
Jakub Andrzejewski
21 min
25 Apr, 2024

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Manejar la seguridad en el desarrollo de frontend es crucial, y el OWASP Top 10 es un recurso valioso para la codificación segura. La lista de riesgos de seguridad está en constante evolución, y el módulo de seguridad de Nuxt proporciona características como encabezados de seguridad, limitación de velocidad y protección contra falsificación de solicitudes entre sitios. Los desarrolladores de frontend deben priorizar la seguridad para evitar filtraciones de información y mitigar riesgos. Comprender la diferencia entre tokens públicos y privados es importante para el manejo seguro de tokens.

Available in English

1. Introducción a las aplicaciones seguras de Next

Short description:

Tradicionalmente, se considera que la seguridad es responsabilidad de los desarrolladores de back-end o ingenieros de DevOps. Sin embargo, con más funcionalidad moviéndose al front-end, es importante que todos prioricen la seguridad. En esta presentación, hablaré sobre las aplicaciones más seguras de Next de forma predeterminada y crearé conciencia sobre los riesgos de seguridad en las aplicaciones web modernas. Un recurso crucial es el OWASP Top 10, un documento que destaca los riesgos de seguridad más críticos. Se reconoce como el primer paso hacia una codificación más segura. La lista de riesgos de seguridad está en constante evolución, como se ve en el sitio web de OWASP Top 10.

o ingenieros de DevOps. Pero hoy en día, cada vez más funcionalidad se está trasladando al front-end. Y es por eso que creo que todos deberían preocuparse por la seguridad. Y también es por eso que he seleccionado este tema para mi presentación de hoy, que son las aplicaciones más seguras de Next de forma predeterminada. Mi nombre es Jakub y trabajo en Allokai como desarrollador senior y defensor. Además de eso, también soy un experto desarrollador de Google en performance web. Soy parte del equipo de Next y también soy embajador de Algolia, Storyblok, Cloudinary y SuperBase. Así que, después de esta presentación, serán unos ninjas de la seguridad. Suena genial, ¿verdad? Pero la realidad es que no es posible. No es posible transferirles todo el conocimiento de seguridad que es necesario para construir aplicaciones seguras desde cero. Entonces, mi idea es hacerlos más conscientes de los riesgos y problemas que pueden aparecer en las aplicaciones web modernas. Porque creo que si están conscientes de estos problemas, podrán proteger su aplicación contra ellos.

Para eso, les recomendaría que se familiaricen con el concepto de OWASP y específicamente OWASP Top 10. OWASP es un documento de concientización estándar tanto para desarrolladores como para seguridad web, especialistas en seguridad de aplicaciones web, y representa un amplio consenso sobre los riesgos de seguridad más críticos para las aplicaciones web. Y como pueden ver, marqué dos lugares aquí. Uno es el documento de concientización estándar, lo que básicamente significa que este OWASP Top 10 es un documento. Y el segundo, riesgos de seguridad. Entonces, es un documento que les mostrará los riesgos de seguridad más populares. OWASP Top 10 también es reconocido por los desarrolladores como el primer paso hacia una codificación más segura. Esta vez también, marcado con color verde, primer paso. Entonces, no deberían considerar OWASP Top 10 como la única solución para hacer que su aplicación sea más segura. Más bien es un primer paso. Como un primer paso sólido. Entonces, si miran el sitio web de OWASP Top 10, verán básicamente esto. Y si nos acercamos un poco, veremos esta lista de los riesgos de seguridad más populares que pueden aparecer en su aplicación web. Y como pueden ver en el

2. Resumen de los riesgos de seguridad

Short description:

La lista de riesgos de seguridad está en constante evolución, ya que surgen nuevos problemas y riesgos. El sitio web de OWASP proporciona una gran cantidad de conocimientos, incluyendo listas de verificación y hojas de trucos para diferentes tipos de aplicaciones. Nos centraremos en algunos riesgos seleccionados, como la ejecución de código en sitios cruzados e inyecciones SQL. El control de acceso roto puede permitir el acceso no autorizado a datos sensibles. Los ataques de denegación de servicio (DOS) y de denegación de servicio distribuido (DDoS) pueden abrumar el servidor de una aplicación, haciendo que no responda. Además, los paquetes maliciosos de NPM y la confusión de dependencias representan una amenaza significativa para las aplicaciones web.

En el lado izquierdo, tenemos 2017, y en el lado derecho, está 2021. Y pueden ver que la lista, tanto el orden como los elementos de la lista, están cambiando. Lo que significa que esta lista está en constante evolución. Todo el tiempo. Porque están apareciendo nuevos problemas o nuevos riesgos y tenemos que hacer que nuestras aplicaciones sean cada vez más seguras en función de los entornos cambiantes. Y también hay un recurso grande, muy grande de conocimiento en términos de hacer que su aplicación sea más segura en el sitio web de OWASP, que básicamente es una lista de listas de verificación, como hojas de trucos, que pueden revisar para ver si su aplicación es segura en un área determinada. Entonces, por ejemplo, tenemos una hoja de trucos para aplicaciones REST, aplicaciones GraphQL, aplicaciones construidas con Ruby, y así sucesivamente.

Entonces, echemos un vistazo a algunos de estos riesgos de seguridad. No vamos a ver todos ellos, nos centraremos solo en algunos seleccionados. Así que, en primer lugar, tenemos las inyecciones. Y los dos principales ataques aquí, o riesgos, son la ejecución de código en sitios cruzados e inyecciones SQL. Y en términos de inyecciones SQL, podrían pensar que esta es una vulnerabilidad muy antigua y que ya no aparece, pero se sorprenderían de cuántos sitios web en producción todavía tienen este tipo de vulnerabilidad. Entonces, en ambos casos, la idea es que el atacante inyecta algún tipo de código malicioso ya sea en SQL, en nuestra base de datos, o en las aplicaciones a través de JavaScript, por ejemplo, y luego este código malicioso básicamente obtiene los datos a los que no debería tener acceso, como usuarios, contraseñas, cosas así. Yendo más allá, tenemos el control de acceso roto. El control de acceso significa que nuestra aplicación permitirá obtener ciertos datos si estamos debidamente autorizados. Entonces, por ejemplo, si estamos conectados o somos parte de una organización o grupo que tiene acceso a cierto recurso. Entonces, el control de acceso roto significa que el atacante puede tener acceso a los datos que básicamente no debería tener. Y mi favorito, que es DOS o DDoS, que significa denegación de servicio, significa que nuestra aplicación se ejecuta en un servidor que solo puede manejar una cierta cantidad de solicitudes. Entonces, si el atacante logra enviar demasiadas solicitudes, nuestra aplicación no podrá responder a estas solicitudes y básicamente se rendirá. Entonces, tenemos DOS, que es la denegación de servicio, y DDoS, que es como la denegación de servicio distribuida, que es el enrutamiento se distribuye entre muchos dispositivos zombi llamados así. Pueden ser teléfonos móviles, pueden ser dispositivos de escritorio, y así sucesivamente. Y tengo un caso interesante adicional, que se llama paquetes maliciosos de NPM y confusión de dependencias. Esto puede sucederle a cualquier persona que esté construyendo aplicaciones web en la actualidad. Entonces, cómo funciona es básicamente que tenemos un usuario que se supone que debe obtener un paquete que está almacenado en un registro privado, como un registro privado de NPM. Podría ser otra cosa. La idea es que este registro es privado y solo los usuarios autorizados deberían tener acceso a él, deberían poder obtener este paquete. Entonces, lo que hace el usuario en cambio, de manera involuntaria, es obtener el paquete con el mismo nombre, pero desde el registro público, como el público de NPM. Y este paquete puede contener un código malicioso. Y este es un caso real. Y esto, desafortunadamente,

3. Securing Applications with HTTP Security Headers

Short description:

El autor de un paquete NPM malicioso apuntó a grandes empresas como PayPal, Microsoft, Apple, Shopify, Netflix, Tesla y Uber, utilizando una shell inversa para obtener acceso remoto a dispositivos. Se otorgó una recompensa de $130,000. La seguridad de las aplicaciones se puede mejorar con las API nativas del navegador, como los encabezados de seguridad HTTP, que informan al navegador sobre las restricciones y los orígenes de los recursos. HTTP AQUIF se puede utilizar en aplicaciones estáticas para emular los encabezados de respuesta del servidor, mientras que los permisos del navegador ayudan a deshabilitar ciertas API en el lado del cliente.

esto está en polaco. El artículo está en polaco, pero puedes buscar los que están en inglés para paquetes NPM maliciosos. Entonces, en este caso, lo que fue la recompensa, porque hay algunos, hay estos desafíos para hackers éticos, que básicamente pueden detectar las vulnerabilidades y obtener recompensas por ello. Entonces, el autor de este ataque logró crear estos paquetes para empresas grandes y populares, como PayPal, Microsoft, Apple, Shopify, Netflix, Tesla o Uber. Así que, grandes empresas. Y este código, lo que hacía, era hacer algo llamado shell inversa. Y esta shell inversa básicamente podía ejecutar comandos en tu dispositivo, de forma remota. Entonces, alguien podía operar o ejecutar comandos en tu computadora portátil o en tu dispositivo de forma remota, por completo. Y la recompensa fue de aproximadamente $130,000 por tal recompensa. Así que, bastante dinero. En cuanto a asegurar tus aplicaciones, siempre digo que las API nativas del navegador son tu mejor ayuda. Entonces, comencemos con los encabezados de seguridad HTTP. La forma en que funcionan es básicamente en el servidor, enviamos esos encabezados de respuesta de seguridad para informar al navegador lo que puede hacer. Entonces, en este caso, por ejemplo, podemos indicarle que solo puede funcionar con HTTPS, que no puede usar el micrófono, como todos los diferentes tipos de servicios, como el micrófono, la geolocalización, la cámara, y así sucesivamente. Y que los recursos en este sitio web, en este navegador, en este sitio web en particular, solo pueden obtener recursos de cierto dominio u origen. Así es como funcionan. Tenemos el nombre del encabezado y el valor. Es posible que hayas oído hablar de la política de seguridad de contenido o las opciones de XFrame, la seguridad de transporte estricta. En realidad, hay bastantes de ellos. Pero la idea es que podemos configurarlos en el servidor para indicarle al navegador lo que puede hacer. Pero esto funciona con aplicaciones de servidor, las aplicaciones que tienen un servidor. Entonces, ¿qué podemos hacer si nuestra aplicación es estática? Podemos usar algo llamado HTTP AQUIF. Espero haberlo pronunciado correctamente. Lo que hace es que podemos configurarlo como una etiqueta meta. Entonces, podemos hacerlo en nuestras aplicaciones estáticas en el puro frontend. Y de alguna manera podemos emular el encabezado de respuesta que se enviaría desde el servidor. En este ejemplo en particular, estamos emulando el encabezado de política de seguridad de contenido. Y lo estamos pasando como contenido, el mismo valor que normalmente se enviaría desde el servidor. También podemos configurar permisos del navegador. Y estos permisos del navegador básicamente nos permiten

4. Mejorando la seguridad con el módulo de seguridad de Nuxt

Short description:

El servidor puede desactivar el acceso a la geolocalización para los usuarios mediante el envío del encabezado de respuesta de la política de permisos. La autenticación básica permite a los usuarios acceder a un sitio web con las credenciales correctas. Podemos mejorar la seguridad de las aplicaciones Vue y Nuxt siguiendo las hojas de trucos y utilizando el módulo de seguridad de Nuxt, que configura la aplicación para cumplir con las recomendaciones de OWASP. La seguridad de Nuxt proporciona encabezados de respuesta de seguridad, limitadores de tamaño y velocidad de solicitud, validación de scripting entre sitios, intercambio de recursos de origen cruzado, métodos HTTP permitidos y protección contra falsificación de solicitudes entre sitios. Una demostración de una aplicación Nuxt simple muestra los encabezados de respuesta en el inspector del navegador.

desactivar ciertas API que se pueden habilitar en el lado del cliente. Entonces, en este caso particular, estamos mostrando la geolocalización. Entonces, si el servidor envía el encabezado de respuesta de la política de permisos con el valor geolocalización con estos corchetes, básicamente, si intentamos acceder a la geolocalización del usuario, este es el code en el medio, obtendremos el error de que la geolocalización ha sido desactivada en este documento por la política de permisos. A continuación, tenemos la autenticación básica. Entonces, la autenticación básica permite al usuario acceder al sitio web solo si proporciona las credenciales correctas. La forma en que funciona es que el servidor envía el encabezado www authenticate con el valor básico realm y el valor de este reino. Y luego los clientes, el cliente que desea authenticate necesita enviar un encabezado de autorización con un básico y estas credenciales. Es como usualmente usuario y contraseña. Y si estas credenciales son correctas, ese usuario puede acceder a este sitio web. De lo contrario, obtendrán un error 401. Pero por favor, no uses este tipo de ejemplo de nombre de usuario y contraseña si tienes la intención de tener este tipo de credenciales para tu autenticación básica. También puedes omitirlo. Porque esto no protege a nadie ni a nada.

Entonces, ¿cómo podemos hacer que las aplicaciones Vue y Nuxt sean más seguras? Hay hojas de trucos muy buenas, tanto en el sitio web de documentación de Vue.js como en la hoja de trucos de seguridad de HTML, que básicamente enumera todas las cosas que puedes hacer en el frontend, en el lado del cliente, para hacer que tu aplicación sea más segura, lo cual te recomiendo encarecidamente que consultes. Sin embargo, si echamos un vistazo a Nuxt, tenemos acceso al módulo de seguridad de Nuxt, que básicamente utiliza OWASP y configura tu aplicación automáticamente para que siga los patrones y recomendaciones de seguridad de OWASP para hacer que tu aplicación sea más segura por defecto. Y lo hace utilizando los encabezados HTTP, algunos de los que ya te mostré, y también el middleware.

Entonces, sin ninguna configuración, Nuxt security viene con encabezados de respuesta de security que funcionan tanto para aplicaciones SSR como SSG, como aplicaciones del lado del servidor y aplicaciones estáticas. Viene con el middleware para limitadores de tamaño y velocidad de solicitud, que básicamente protege tu aplicación de demasiadas solicitudes y solicitudes demasiado grandes. Tenemos acceso a la validación de scripting entre sitios, que nos protege de situaciones en las que alguien envíe código malicioso a través de solicitudes GET o POST. Tenemos acceso al intercambio de recursos de origen cruzado, que es como un curso en resumen, donde podemos decidir desde dónde esta aplicación puede obtener los datos, desde qué orígenes. También podemos usar el middleware para los métodos HTTP permitidos, donde podemos decidir qué métodos están permitidos para ciertos puntos finales. Entonces, en ciertos puntos finales, es posible que solo queramos habilitar solicitudes POST o eliminar o GET. Y también tenemos soporte para la protección contra falsificación de solicitudes entre sitios.

Pasemos a la demostración. Tengo aquí una aplicación Nuxt en ejecución, que básicamente es una aplicación Nuxt muy simple. No tiene ninguna biblioteca de UI, no tiene ningún componente. Es solo una simple aplicación de Hola Mundo Nuxt. Entonces, si la inspeccionamos en el navegador, veremos esta página de bienvenida de Nuxt. Y ahora, si la inspeccionamos, vamos a la red y actualizamos la página. Aquí, veremos los encabezados de respuesta. Tenemos conexión, longitud del contenido, tipo de contenido,

5. Configurando el Módulo de Seguridad de Nuxt

Short description:

Al habilitar el módulo de seguridad de Nuxt se agregan encabezados de seguridad a la respuesta, incluyendo la política de seguridad de contenido, la política de apertura de origen cruzado y la política de permisos. La validación de scripting entre sitios ayuda a prevenir la inyección de código malicioso. La configuración se puede realizar en el archivo config.ts de Nuxt, lo que permite ajustes globales y específicos de los encabezados. El módulo también proporciona funcionalidad de limitación de velocidad.

fecha, x powered by. ¿Qué sucederá cuando habilitamos o descomentamos el módulo de seguridad de Nuxt es que cuando inspeccionemos este mismo documento, ahora veremos que la sección de encabezados de respuesta es mucho más grande. Tenemos encabezados de seguridad para una política de seguridad de contenido, una política de apertura de origen cruzado, una política de permisos y muchos más configurados automáticamente para nosotros, según las recomendaciones de OWASP. Esto viene por defecto en términos de encabezados de respuesta. También tenemos acceso a la validación de scripting entre sitios, lo que básicamente significa que si decimos texto y aquí decimos script, digamos alerta uno, y lo cerramos, script, así, lo que sucederá Olvidé que necesita ser un parámetro. es que obtendremos una solicitud de error 400. Esto básicamente significa que esta validación subyacente de scripting entre sitios desencadena este texto que enviamos en esta solicitud GET como un código malicioso. Bien, esto es sobre algunas de las características. Para otras, necesitaría pasar alguna configuración. Entonces, aquí, en el archivo config.ts de Nuxt, generalmente pasamos alguna configuración ya sea a Nuxt framework o a los modules que forman parte de nuestra aplicación. Tenemos acceso al objeto de security, donde podemos configurar toda nuestra configuración de seguridad de Nuxt. Entonces, aquí, tengo acceso también a los encabezados donde puedo decir, por ejemplo, que quiero que la protección X-XSS sea uno. Y si inspeccionamos el navegador, pero ahora sin esto, veremos que ahora la protección X-XSS es uno. Entonces, cambiémoslo a cero. Y vemos que se ha cambiado. Configurar encabezados de esta manera es global. Esto significa que estos encabezados se configurarán globalmente de esta manera. Sin embargo, con el módulo de seguridad de Nuxt security, también tenemos acceso a reglas de ruta. Entonces, lo que puede suceder es que podemos hacer reglas de ruta, pasar nuestra ruta. Digamos secreto. Y aquí, podemos decir security. Y lo mismo que antes, encabezados. Y aquí, podemos decir X-XSS protección uno. Esto significa que para la ruta con slash secreto, el valor del encabezado X-XSS protección se establecerá en uno. Y esto funciona para todos los encabezados y para todas las funcionalidades de middleware que forman parte del módulo. Quiero mostrarte una cosa más.

6. Usando el Limitador de Tasa y Conclusión

Short description:

Configuraré el limitador de tasa para permitir cinco tokens por intervalo de 10 segundos. Esto bloqueará las solicitudes excesivas. El módulo de seguridad de Nuxt proporciona características adicionales como ALF y falsificación de solicitudes entre sitios. Recuerda que ningún sistema es infranqueable, así que intenta crear sistemas que sean difíciles de romper. Consulta la documentación de seguridad de Nuxt para obtener más información.

Aquí, lo que haré es configurar el limitador de tasa. Y diré tokens por intervalo. Y lo estableceré en cinco. Y el intervalo, lo estableceré en, digamos, 10 segundos.

Entonces, lo que sucederá ahora es que si comienzas a hacer spam en el botón de actualización aquí, después de algunas solicitudes, seremos bloqueados. Y veremos que hay demasiadas solicitudes, de cuatro a nueve. De acuerdo. Así que, el módulo viene con mucho, mucho más. Tenemos acceso a ALF básico, como mencioné, la falsificación de solicitudes entre sitios y muchas, muchas más. Así que asegúrate de consultar la documentación de seguridad de Nuxt para aprovechar al máximo estas características. Permíteme volver a la presentación. Esto es solo la punta del iceberg en términos de patrones de seguridad. Y quiero decirte que no existen sistemas infranqueables. Solo existen aquellos que son tan difíciles o que requieren tanto tiempo para romper que los atacantes básicamente se rinden. Así que mi recomendación para ti es ser uno de esos sistemas. Sé uno de esos sistemas que son difíciles de romper para que los atacantes se rindan. Muchas gracias por estar aquí conmigo. Asegúrate de consultar la seguridad de Nuxt. Si hay algo que creas que falta en el módulo o que se podría mejorar, solo avísanos a través de problemas o discusiones. Siempre estamos abiertos a recibir comentarios. Y si quieres contactarme en algún lugar, asegúrate de hacerlo a través de X o DevTool. Estoy allí como Jacob Andrewski. También tengo un canal de YouTube llamado Jacob, igual que en GitHub. Así que, gracias por recibirme y disfruta el resto de la conferencia.

QnA

OWASP Top 10 y Seguridad Frontend

Short description:

Jacob hizo una pregunta complicada sobre los tres problemas de seguridad más populares en el OWASP Top 10. El control de acceso roto, las inyecciones y las fallas criptográficas son respuestas válidas. Para probar la seguridad de una aplicación Nuxt, puedes utilizar securityheaders.com y buscar un escáner de encabezados de seguridad. Los desarrolladores frontend deben estar conscientes de las preocupaciones de seguridad para evitar filtraciones de información y mitigar riesgos en las aplicaciones web modernas, incluso si no implementan medidas de seguridad exhaustivas.

Entonces, con respecto a la pregunta que publicaste en la encuesta, era cuáles son los tres problemas de seguridad más populares en la última edición de los documentos OWASP Top 10. En algún momento, el público tenía razón porque Jacob en realidad hizo una trampa y quería decir que los tres son respuestas válidas. En algún momento, tuvimos un 50-50. Pero ahora, sí, las personas que eligieron el control de acceso roto están equivocadas, las inyecciones están equivocadas y las fallas criptográficas están equivocadas porque son los tres al mismo tiempo. Así que fue una pregunta trampa. Pero está bien. Volvamos y pasemos a algunas preguntas y respuestas. De todas las preguntas que tuvimos, una de las más interesantes es si hay herramientas para probar mi aplicación Nuxt en busca de problemas de seguridad. Claro. Primero, puedes simplemente escribir securityheaders.com. Este sitio web te permitirá auditar tu sitio web en busca de encabezados de seguridad y si cumplen con los valores recomendados. Funciona de manera similar a Lighthouse, por ejemplo, o page speed.dev, donde ingresas una URL que deseas auditar. Pero en este caso, se trata de rendimiento. Pero en nuestro caso, se trata de la validación de los encabezados de seguridad. Así que, sin duda, securityheaders.com. No tengo más en este momento, pero probablemente si buscas en Google un escáner de encabezados de seguridad, probablemente encontrarás más herramientas que te puedan dar la respuesta correcta. De acuerdo. Tiene sentido. Otra pregunta que tenemos es una de las mías, pero sigue siendo la más votada. ¿Crees que un desarrollador frontend debería conocer estas preocupaciones de seguridad en absoluto? Sí, diría que es igualmente importante. No de la manera en que como desarrollador frontend, estarás desarrollando la misma cantidad de regulaciones o protecciones de seguridad para tu aplicación. Es más bien si estás consciente de los problemas de seguridad que pueden aparecer en las aplicaciones web modernas, es menos probable que filtres algún tipo de información. Puede ser un token de acceso. Puede ser una página que solo debería estar disponible para un usuario que tenga los derechos apropiados. Así que siempre creo que si estás consciente de estos problemas, problemas de seguridad, es menos probable que tengas este tipo de riesgos en tu aplicación web, incluso como desarrollador frontend. Porque inicialmente, cuando pensamos en el desarrollo frontend, pensamos en estilos, en HTML, tal vez en algunas animaciones. Pero honestamente, hoy en día, cada vez más lógica se está trasladando al frontend. Tenemos frameworks como Next, donde básicamente podemos construir aplicaciones de pila completa con él. Entonces, considerando que estos frameworks son principalmente frontend, también tienen un poco de backend, estos desarrolladores frontend necesitan tener este conocimiento de seguridad, al menos el básico de los riesgos. Es posible que no necesites entender cada riesgo y conocer todas las protecciones de seguridad, pero si estás consciente de estos riesgos, es menos probable que los tengas en tu aplicación web.

Token Handling and NUC Security

Short description:

Cuando se trata de tokens, es importante entender la diferencia entre tokens públicos y privados. Para la seguridad de NUC y aplicaciones estáticas, como las aplicaciones SSG, el módulo de seguridad de NUC proporciona mejoras de seguridad como la política de seguridad de contenido y la capacidad de eliminar registros de consola. Si tienes más preguntas, no dudes en preguntar en Discord. ¡Gracias por participar!

Sí. También suelo tener muchas personas en Stack Overflow que preguntan, hey, tengo este token. ¿Qué hago con él? ¿Cómo lo oculto? Y a veces lo complicado es que tienes tokens públicos y privados. Entonces, dependiendo de eso, necesitas encontrar una manera de lidiar con eso. Así que, sí, lo que suelo recomendar a esas personas es simplemente, hey, probablemente tengas un equipo de backend. Ve y habla con la gente allí, para que te puedan explicar un poco más. Porque, de lo contrario, si tomas un token privado con algo de dinero o algún servicio detrás, sí, puede ser un poco complicado. ¿Qué hay de la seguridad de NUC y las aplicaciones SSG, como las aplicaciones de generador estático?

Sí, claro. Entonces, si pensamos en la seguridad en general, generalmente pensamos en aplicaciones que involucran algún tipo de servidor. Porque, por ejemplo, incluso con los encabezados de respuesta, como su nombre sugiere, son encabezados de respuesta. Entonces, deben ser enviados desde el servidor al cliente y el cliente, cuando recibe estos encabezados, el navegador sabe cómo comportarse. Pero con la seguridad de NUC, también la implementamos de tal manera que incluso si tu aplicación es estática, como una aplicación SSG estática, aún puedes beneficiarte de ciertas mejoras de seguridad del módulo. En primer lugar, obtienes la política de seguridad de contenido como un HTTP EQIF, creo que lo pronuncio correctamente, como la etiqueta meta. Y esto es una cosa. Y una cosa más es que también obtienes el soporte para eliminar los registros de consola. Esta es una pequeña función de utilidad que permite ocultar los registros de consola, los depuradores de consola y otros métodos de consola que podrías olvidar mientras desarrollas. He tenido situaciones en las que tal vez no filtré información, pero dejé algunos registros de consola en lugares donde no deberían estar.

De acuerdo. De acuerdo, de acuerdo. Supongo que eso es todo. Muchas gracias de nuevo. Si tienes alguna otra pregunta, si no se respondieron, puedes ir a Discord, puedes preguntar allí. Y algunos oradores ya han dado respuestas sobre temas anteriores. Así que, sí, si realmente quieres obtener la respuesta, siéntete libre de hacer lo mismo. Así que, gracias de nuevo por tu participación, Jacob. Te deseo un día increíble. Continuemos con la conferencia. Gracias. Nos vemos.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
The Future of Performance Tooling
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
Optimizing HTML5 Games: 10 Years of Learnings
JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Optimizing HTML5 Games: 10 Years of Learnings
Top Content
The open source PlayCanvas game engine is built specifically for the browser, incorporating 10 years of learnings about optimization. In this talk, you will discover the secret sauce that enables PlayCanvas to generate games with lightning fast load times and rock solid frame rates.
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Building WebApps That Light Up the Internet with QwikCity
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Miško Hevery
Miško Hevery
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
Alice De Mauro
Alice De Mauro
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
0 to Auth in an hour with ReactJS
React Summit 2023React Summit 2023
56 min
0 to Auth in an hour with ReactJS
WorkshopFree
Kevin Gao
Kevin Gao
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool. There are multiple alternatives that are much better than passwords to identify and authenticate your users - including SSO, SAML, OAuth, Magic Links, One-Time Passwords, and Authenticator Apps.
While addressing security aspects and avoiding common pitfalls, we will enhance a full-stack JS application (Node.js backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session securely for subsequent client requests, validating / refreshing sessions- Basic Authorization - extracting and validating claims from the session token JWT and handling authorization in backend flows
At the end of the workshop, we will also touch other approaches of authentication implementation with Descope - using frontend or backend SDKs.
React Performance Debugging
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
React Summit 2023React Summit 2023
109 min
Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
Workshop
Asaf Shochet Avida
Eitan Noy
2 authors
In this hands-on workshop, we’ll equip you with the tools and techniques you need to create accessible web applications. We’ll explore the principles of inclusive design and learn how to test our websites using assistive technology to ensure that they work for everyone.
We’ll cover topics such as semantic markup, ARIA roles, accessible forms, and navigation, and then dive into coding exercises where you’ll get to apply what you’ve learned. We’ll use automated testing tools to validate our work and ensure that we meet accessibility standards.
By the end of this workshop, you’ll be equipped with the knowledge and skills to create accessible websites that work for everyone, and you’ll have hands-on experience using the latest techniques and tools for inclusive design and testing. Join us for this awesome coding workshop and become a ninja in web accessibility and inclusive design!