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.
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:
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:
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.