fix: Secure x-forwarded-* headers from untrusted proxies but trust all apiml proxies (v2)

[richard-salac]

Description

This is a follow-up to issue #4148. In that issue, a new configuration option was added to define a pattern for validating whether requests with x-forwarded-* headers originate from trusted proxy servers. These headers are only processed if the source is deemed trustworthy and the headers are considered safe.

While this security issue was addressed, the new configuration option must now also be set for APIML gateways to ensure that x-forwarded-* headers are trusted. This configuration is only necessary in scenarios where requests traverse multiple gateways — a common pattern in hybrid deployments such as multi-sysplex environments or setups involving both z/OS and Kubernetes. In such cases, multiple APIML domain installations are interconnected through central gateways. Although such deployments are relatively rare, they are typically more complex — and we want to avoid introducing additional complexity.

To support this, APIML domains can be onboarded to the central gateway through additional gw registrations (and vice versa). We utilize these registrations to fetch APIML gateways information from remote discovery services. Based on this data, we dynamically update the list of trusted proxies so that APIML proxies are consistently treated as trusted.

Non-APIML gateways still must be configured to be trusted.

Linked to # (4148)
Part of the # (epic)

Type of change

Please delete options that are not relevant.

• fix: Bug fix (non-breaking change which fixes an issue)
• feat: New feature (non-breaking change which adds functionality)
• docs: Change in a documentation
• refactor: Refactor the code
• chore: Chore, repository cleanup, updates the dependencies.
• BREAKING CHANGE or !: Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the style guidelines of this project
• PR title conforms to commit message guideline ## Commit Message Structure Guideline
• I have commented my code, particularly in hard-to-understand areas. In JS I did provide JSDoc
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The java tests in the area I was working on leverage @nested annotations
• Any dependent changes have been merged and published in downstream modules

For more details about how should the code look like read the Contributing guideline

[arxioly]

Could it be final?

Suggested change

	private String originalProxyAddressProperty;
	private final String originalProxyAddressProperty;

[richard-salac]

done

[arxioly]

LGTM. Thanks!

[sonarqubecloud]

Quality Gate passed

Issues
19 New issues
0 Accepted issues

Measures
0 Security Hotspots
91.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud