5 consejos para que tu API REST sea más seguro

[@nelligescorcia]

La inyección de código desde hace tiempo la conozco pero hasta ahora no la he implementado, gracias por lo de let's encript me vas ahorrar mucho 🎉🎉, chévere si haces un video sobre librerías que faciliten esa aplicación, yo normalmente he trabajado con .net, Java y js(express para backend y vue front)

[@roy_c]

Agregaria tener cuidado con los logs. Evitar loguear información sensible, o si es necesario aplicar una máscara. Muchas veces ponemos logs de debug para ver los inputs y despues ahi quedan, logueandose en texto plano las passwords, secrets, keys, etc.

[@erickjhormanromero6905]

si eso es muy importante pero eso se puede organizar con applicacion como elastick logs o se configura el server para que todo log que vea lo convierta en .INFO por ejemplo, AWS secrets o vault para el manejo de la data sensible

[@SimaDamian]

Me paso que puse un sistema de log que logeaba cada request a base de datos y los datos de body... entonces en definitiva terminaba logeando los password cuando el usuario invocaba el auth/login. :( no generó problema porque nos dimos cuenta en testing.

[@javierrenteria3195]

"tu backend ya valió". Hahahahahahaa. Es verdad.

[@ManuelZapata]

jajjaja

[@PabloMartinez-sz6pv]

Hola Manuel, que calidad de contenido (HD), siempre que veo tus vídeo algo bueno me llevo, o para saber qué tan bien estoy con lo que hago. Como práctica adicional me encontré con que la otra vez en un servicio había que saltear el API key , sumado con el nombre de usuario y la fecha actual , no se qué tan buen práctica sea pero cada vez que había que usar ese servicio daba demasiado asco. Gracias por compartir Manuel un saludo 👋

[@rodrigofigue]

muy interesante, esto es oro para quien esta aprendiendo y quiere consejos de seguridad

[@CesarSilvaR]

Excelente información, el contenido de tus videos es super valioso. Muchas gracias por compartir

[@Danyospina27]

Excelente video, claro y concreto. Muchas gracias Manuel

[@AndresSossa]

Super buen video, otra seria tener una lista blanca de dominios desde donde te pueden invocar, casos específicos

[@ManuelZapata]

Buenísimo! SI no es un API público y sabemos previamente desde donde es válido que invoquen, es una buena práctica!

[@diegomarroquin4369]

Cómo se podría hacer eso? Me interesa

[@AndresSossa]

@@diegomarroquin4369 depende las tecnologias que uses. Si estas en nube puedes hacerlo a nivel de apigateway o WAF, sino, lo puedes hacer con filtro cuando invoque tu api, validas en los headers desde donde te estan invocando y ya lo validas con una lista en bb.dd o un archivo...

[@mirxtremapps]

Tener cuidado con que guardamos en el payload del jwt y no dejar el secret expuesto. Acabo de encontrar este canal, muy completo felicitaciones bro!

[@rogergalindo6631]

Amigo muy buen video. Justo ahorita estoy adentrandome en eso de la seguridad en el consumo de API REST... Una duda como poder evitar que la petición json no sea legible para un atacante y no la pueda interceptar al enviarla a un API REST desde un frontal

[@cristiancalichio5335]

Muchas gracias Manuel por un nuevo aporte a la comunidad y por dejar material extra para profundizar!!! Saludos desde Argentina!

[@ManuelZapata]

Con todo gusto Cristian! Saludos desde Colombia.

[@joseangelramirezhernandez3269]

Yo agregué otro feacture a mi api y es el siguiente siempre que un usuario se autentica en mi api genero el token y genero otro id único y lo guardado encriptado en mi base de datos y en cada petición que hace el usuario pues valido ese id único en mi caso en específico un usuario no puede estar logueado más de una vez en un dispositivo, haciendo esto me garantiza que siempre habrá una sola session activa y que si un usuario pierde su dispositivo lo que se hace es que esa key única se resetea y automáticamente ya el dispositivo extraviado/ perdido ya no podrá utilizar dicha app

[@FrankJaimeFabianPuente-sy1yr]

Hago lo mismo en mis sistemas, me funciona bien por ahora

[@ManuelZapata]

Interesantísimo, Jose Angel! Generas una especia de "Device ID". Algunas aplicaciones también lo usan para llevar registro de los dispositivos que el usuario ha usado. Gracias por compartir!

[@erickjhormanromero6905]

pero pienso que en cada peticion hacer un llamado a base de datos no seria una buena opcion en recursos y costos por ejemplo si me hacen 1000 peticiones diarias, pienso que podrias mejoralo usando el mismo enfoque pero guardando ese valor en redis y asi evitas muchos llamados a la base de datos , no se si ese es tu ejemplo real en tu sistema o si no usar AWS para eso

[@joseangelramirezhernandez3269]

@@erickjhormanromero6905 gracias por la sugerencia pero en mi caso cada petición involucra el acceso a la base datos pero no está mala tu sugerencia es válida y aceptable

[@abnergranados9915]

Al ser un api, pueden ocurrir diferentes sesiones para un mismo usuario, desde dispositivos móviles u otros equipos, eso no limitaría el uso?

[@gustavoayala7385]

Muchas gracias por el contenido de buena calidad constante. Muy util los consejos. Una cuestión que me surgió es diferenciar entre la utenticación de la aplicación cliente (digamos un fronend en nuxt.js o una app de celular) y la autenticación de un usuario. A esto también se encuentra la cuestión de los endpoints que no requieren autenticación para "invitados" (guests), me parece que habría que agregar que aquí sería importante incorporar algún tipo de throttling para evitar ataques de fuerza bruta en el login, o DoS (Denial of Services) en los demás servicios.

[@MrOsnayder]

Super. A mi me falta mejorar la sanitización del código. Hasta donde va mi conocimiento en este tema, en el que estoy empezando, no se me ocurre algun consejo que haga falta aún. De acuedo a lo que he investigado, sí tengo entendido que los jwt son las mejor opción para autenticación.

Muy buenos consejos, sabía unos cuantos pero otros no. Gracias

[@JRicharDavidG]

Muy bueno y útil tu canal, felicidades. 🎉 Le agregaría cifrado hibrido

[@iorusoul]

Tambien es bueno exponer las apis detras de proxies inversos oara proteger al servidor q presta el servicio, osar orm aeguras para evitar inyecciones de sql , utilizar dtos para evitar que los usuarios conozcan las estructuras principales de los datos al transferirse. Guardar las keys secretas en los lugares que deberian para que nunca se filtren y esten en una zona segura del servidor, deshabilitar accesos remotos en puntos innecesarios. Etc etc etc

[@AnthonyShelby]

Gracias Manuel , muy bien explicado y de mucha ayuda !

[@ManuelZapata]

Me encanta leer eso. Gracias Anthony!

[@edwinspiredev4930]

Excelente información, me encantó.

[@ManuelZapata]

🙌

[@luimost]

Agradecido por tu video (Y)

[@ManuelZapata]

Gracias a ti por verlo

[@NatanRobles]

¡Consejos buenos y válidos... excelente!

[@martineduardovega724]

gracias por compartir este conocimiento!!

[@rko_182]

Fabuloso video Manuel, podrias subir uno que hable de Api Manager y Api Gateway he buscado pero no hay nada

[@EdsonFerOropeza]

No sabia sobre bleach, buenos consejos.

[@seulflowstyle]

Class Validator en TypeScript y con NestJS es muy bueno, aprovechando una duda ¿como usar idle con JWT ? Saludos Manuel Zapata ya extrañaba tus videos

[@alejogallego6303]

Muy buen video Manuel, super el contenido.

[@ManuelZapata]

Gracias Alejo!

[@studipitytries]

Genial. Gracias por la info!

[@computacionysistemastomaso7270]

Excelente recomendaciones, nunca he usado la 3,5 y tenía fallas en la 4. Con respecto a la 5ta Recomendación sanitization = desinfección Sigo investigando para conseguir otras sugerencias de seguridad.

[@1986elkin1]

Excelente, en mi aplicaciones el concejo 5 siempre lo paso por alto o se me olvida

[@newzord]

Excelente video!!! 👍🏻

[@Juan-hg2ts]

Excelente, gracias

[@alexandrohdez3982]

Excelente video

[@247431]

Vale la pena poner autenticación o JWT a las API si son usuarios no autenticados y se llama desde el cliente? creo que falta validación CORS y API Gateway

[@SimaDamian]

Yo implemento así: El cliente web usa JWT con lo cual cada request que realiza sobre la api se valida como JWT con caducidad y su correspondiente refreshToken (manejado por authentication) en simultaneo defino las API_KEY usadas por los clientes estaticos como un JWT porque de esta forma puedo definir dentro del mismo API_KEY los permisos que tendra ese cliente en particular. La diferencia está en el JWT de API_KEY es sin caducidad y debe estar en un archivo de configuracion. mientras que el JWT estandar esta definido por cada login / refreshToken

[@jhonrodriguez3067]

que solo se debe permitir el ingreso de datos necesarios, es decir, si tenemos parámetros de entradas en nuestra clase que no se utilizan , no exponerlos , indicar que datos son serializables y validar el dominio de los datos

[@ManuelZapata]

Importante! Gracias por el aporte, Jhon!

[@JoseLuis-sr4xw]

Muy interesante, por cierto, una API REST es diferente a los Microservicios que tanto escucho ? o son lo mismo?

[@ManuelZapata]

Son dos conceptos diferentes. Un API REST se podría usar o no con microservicios. Puede haber microservicios con o sin APIs REST.

[@RicardoHernandez-vr1bp]

me falta mejorar en los parametros que no se ejecute el código malicioso como javascritpt y la implementacion de una identidad digital, a traves de la criptografia es un tema muy interesante

[@cristianaguilar4170]

Excelente 👌

[@moviedomof]

jwt es muy util pero se pueden robar y hay que implementar un sistema de invalidacion. estaria bueno que alguien explique bien algun mecanizmo de resolucion , Muchos usan invaidar por [ip+userGuid] pero es problema cuando hay un nginx por delante. y por otras cosas saludos

[@transformers886]

casbin tan dinamico es para el acceso a las api

[@freddycastillo9385]

Pregunta de principiante.. para ssl debo tener obligado?

[@ManuelZapata]

Podrias volver a escribir la pregunta? No entendí.

[@Jel.Awesh.M]

¿Cómo manejarías el hecho de que un API sea llamdo multiples momentos por el cliente? Ya sea que por que el cliente no tiene validación alguna y le den click muchas veces a un botón o que incluso haya algún tipo de boto haciendo varias llamadas.

[@SimaDamian]

Hola, Si es una API REST no tiene la responsabilidad de contemplar ese caso. Desde mi punto de vista veo dos Puntos: 1 - porque motivo tu cliente esta invocando varias veces lo mismo? es un bug del cliente. 2 - si es un ataque (aplicacion de tercero) tendrías que ver la forma de invalidar dicho cliente y agregarlo a a una lista negra y no procesar sus consultas dada que parecen que pueden dañar el funcionamiento normal tu sistema. Pero eso se tendría que hacer en una capa de infrestrucutura.

[@Jel.Awesh.M]

@@SimaDamian gracias por responder, en este caso el cliente está fuera de nuetro poder, así que sólo podemos nos queda asegurar nuestro API.

[@FcoJavierNW]

Saludos, en ese caso lo mejor es contar con seguridad perimetral y en ella colocar los umbrales de DoS (Denial of Service). Teniendo varios sitios en una granja de servidores hacerlo en las aplicaciones es más desgastante. Si optas por hacerlo en tus aplicaciones, solicita que te envíen las cabeceras X-Forwarded-For, desde el Firewall, sino solo ves la IP del balanceador desde tu aplicación.

[@jimezam]

* Sanear 👍

[@moisescaicedo4078]

He encontrado aplicaciones que envían las credenciaes de base de datos desde el frontend 😭😭😄😄

[@ManuelZapata]

Esa nunca la había escuchado!! 😱😱😱

[@moisescaicedo4078]

@@ManuelZapata pa que vea :v

[@erickjhormanromero6905]

como es eso? cuales ?

[@SimaDamian]

El que lo diseño si que tiene mente abierta! xD

[@erickjhormanromero6905]

Okta compro auth0

[@ManuelZapata]

Buenísimo el dato. No sabía.

[@erickjhormanromero6905]

@@ManuelZapata Yup entonces a usar Okta. deberias hacer un video de las ventajas de okta y hasta hacer un mano a mano entre okta y keycloak para este apartado. claro esta desde el punto de vista de arquitecturas