La sección 3 sobre escapar HTML sugiere un mecanismo frágil (escapar explícitamente) en lugar de uno sólido (separar por diseño safe strings de unsafe strings y obligar a que todo string se considere unsafe a menos que sea explícitamente marcado como safe, cosa que existe en frameworks modernos).
La sección 5.1 de contraseñas olvida mencionar que NUNCA se debe poner un máximo al largo de una contraseña.
La sección 6 de manejo de id sesión presume la existencia de "ids de sesión" que no son una necesidad (ej: signed cookies no requiere un id de sesión porque no hay una sesión en ninguna base de datos o servidor). También en la sección 6 falta considerar el tradeoff de que forzar muy seguido a los usuarios a loguearse puede hacer mas probable una fuga de la contraseña o que el usuario establezca una contraseña débil.
La sección 13 tiene una definición inventada de TDD (y sería raro recomendar a todo el mundo TDD pero entonces debieran cambiar el título de la sección para evitar confusión con una práctica ampliamente practicada que no corresponde con lo descrito en la sección).
Extraño en este capítulo que no se recomiende forzar HTTPS everywhere (y el uso de HSTS para forzar HTTPS en conexiones futuras).
La elección de tecnologías (aunque me gusten varias) parece caprichosa/arbitraria si no se indica el criterio para escogerlas. Además, si existiera un criterio eso abre la puerta a que la lista evolucione y no se quede pegado en lo que se usa el 2018. BTW, JQuery está cayendo en desuso y se ve muy raro en esa lista.
En general es un antipatrón que aparezcan verbos dentro de URLs que hayan sido modeladas como REST. Y hay ejemplos que tienen ese antipatrón. Por ejemplo "buscar" podría ser reemplazado por "busqueda" para hacerlo mas aceptable.
👍 100%
Frameworks
Me faltó el framework Ruby On Rails , básicamente porque integra todas las buenas prácticas mencionadas. log filter, secretos, xss, safe_strings, y mas mucho mas. por algo
https://git.gob.cles un gitlab, que es un Rails. 😄También se echa de menos Go para microservicios. Incluso Elixir.
REST
Se contempla REST, y está bien documentado. Sería buena considerar a GraphQl como alternativa a REST.
USO DEL IDIOMA EN EL CÓDIGO
Solo un alcance. El mezclar variables en castellano con lenguajes que son eminentemente en inglés , en mi opinión, genera que el programa quede escrito en espanglish. no bueno.