Defensa en profundidad sin capas decorativas

La defensa en profundidad es poner varias barreras de modo que el fallo de una no deje el activo al descubierto. La palabra que importa es independiente: dos capas valen por dos solo si fallan por motivos distintos. Dos filtros con las mismas reglas fallan juntos ante la misma petición; un control que se apoya en lo que otro ya comprobó cae cuando alguien llega por un camino que no pasa por el primero.

Al leer un diseño, cada capa se interroga con tres preguntas: qué detiene de verdad (no qué dice el documento), qué pasa si alguien llega sin pasar por las capas anteriores, y si su configuración real coincide con la que se declara. Una capa que no supera esas preguntas es decorativa: da tranquilidad en la diapositiva y nada en producción.

El documento presenta al filtro web A como la capa que detiene inyecciones y scripts. Una capa se mide por su configuración exportada, no por la frase del documento: un filtro que anota coincidencias sin detener nada sirve para conocer el tráfico y afinar reglas, pero no protege a nadie mientras siga así.

Abre filtro-web.txt y lee los dos bloques. Fíjate también en de dónde salen las reglas del segundo filtro y qué excluye.

Una capa solo protege lo que pasa por ella. En el diagrama, la pasarela de API valida la sesión de todo lo que entra por un prefijo; pero un balanceador puede tener más reglas que el diagrama oficial, y una aplicación heredada suele conservar su propia entrada directa. Ese camino lateral es exactamente el que vuelve inútiles las capas que el documento cuenta.

Abre balanceador.txt y compara cada regla con el diagrama.

El servicio de recetas sabe quién emite una receta leyendo una cabecera que la pasarela añade tras validar la sesión. Mientras todo pase por la pasarela, funciona. Pero el servicio no comprueba nada por sí mismo, y una petición que entra por el camino lateral trae la cabecera que traiga. MITRE llama a esto violación de un límite de confianza (CWE-501): datos de un lado no confiable tratados como si vinieran del lado verificado. Es uno de los fallos que OWASP cita como típicos del diseño inseguro.

Abre recetas-servicio.txt y decide qué corrección de diseño hace que esta capa valga por sí sola.