Are 13.2.4 and 13.2.5 duplicates?

Abierto
  • ¿Algo no está bien?
#3,343 5 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@elarlang ya está trabajando en esto.

Desde el 5/3/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

V13 (prev V14)

Background

V13.2.4 and V13.2.5 sit next to each other in the Backend Communication Configuration section and both require allowlisting external communications:

# Description Level
13.2.4 Verify that an allowlist is used to define the external resources or systems with which the application is permitted to communicate (e.g., for outbound requests, data loads, or file access). This allowlist can be implemented at the application layer, web server, firewall, or a combination of different layers. 2
13.2.5 Verify that the web or application server is configured with an allowlist of resources or systems to which the server can send requests or load data or files from. 2

V13.2.5 appears to be a specific instance of V13.2.4 — if you satisfy V13.2.4 by configuring an allowlist at the web server level, you've also satisfied V13.2.5. Is there a reason to keep both?

How we got here

V13.2.5 is a direct descendant of V12.6.1 in v4.0.3:

Verify that the web or application server is configured with an allow list of resources or systems to which the server can send requests or load data/files from.

The wording changed only minimally ("allow list" → "allowlist"). It was moved from V12 to V14 in #1324/#1343, then renumbered through the v5.0.0 pipeline (V14.7.1 → V14.6.1 → V14.7.4 → V13.2.5).

V13.2.4 has a more complex history. Its requirement slot traces back to V4.3.3 in v4.0.3, which was about step-up authentication and anti-fraud controls. That requirement was modified in #1437 to focus on protecting configuration changes for service credentials, moved to V14.7.3, and renumbered to V13.2.4. However, in #2951, @elarlang noted that the old V12.6.1 wording (then at V13.2.5) was too narrow — requiring configuration specifically in the "web or application server" when in practice the allowlist might be enforced by a WAF, firewall, application code, or a combination. @jmanico and @tghosth agreed and collaboratively drafted broader, technology-agnostic wording.

The agreed text was intended as a replacement for the old V12.6.1 wording. Instead, it was written into the V13.2.4 slot (e4c9d291, PR #2982), leaving V13.2.5 unchanged. The overlap between the two was never discussed.

Question

Should V13.2.5 be removed/merged into V13.2.4?

One reading is that they form a deliberate pair: V13.2.4 as the broad principle (allowlist at any layer) and V13.2.5 as a specific implementation requirement (configure it at the server level). But this distinction isn't obvious from the text, and an auditor could reasonably satisfy V13.2.5 by pointing to the same control that satisfies V13.2.4.

Note: this also relates to the discussion in #3244 about the overlap between V1.3.6 and V13.2.4, where there is a proposal to either fold V1.3.6 into V13.2.4 or split into per-feature (V1/V2) and infrastructure (V13) requirements. If V13.2.4 is narrowed to infrastructure-only in that discussion, V13.2.5 would overlap even more directly.

Lenguaje dominante
HTML
Estrellas
3.8k
Forks
855
Merge medio
1 d 9 h
PR fusionados (30 d)
8

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OWASP/ASVS

Todos los issues de OWASP/ASVS

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.