Improper Certificate Validation Affecting steeltoe.security.authorization.certificate package, versions [,4.3.0)

Affected versions of this package are vulnerable to Improper Certificate Validation through the UseCertificateAuthorization flow in Authorization.Certificate, specifically the AddOrgAndSpacePolicies authorization path that trusts the X-Client-Cert header. An attacker can bypass SameOrg and SameSpace authorization checks by supplying a forged X-Client-Cert header on a network-accessible request. If the application exposes protected endpoints through Cloud Foundry routing and uses certificate-based authorization for inter-service access, the attacker can impersonate a trusted client certificate and gain unauthorized access to endpoints intended only for the same organization or space.

Workarounds

• Restrict UseCertificateForwarding to trusted proxy source IPs by configuring ForwardedHeadersOptions.KnownProxies and KnownNetworks; this prevents untrusted clients from supplying a spoofed certificate header directly.
• Change the forwarding header to X-Forwarded-Client-Cert so Cloud Foundry Gorouter and Envoy strip inbound untrusted copies of that header; this blocks header spoofing on network-accessible requests.
• Add a second authorization check for sensitive endpoints, such as a shared secret or mutual TLS at the proxy layer; this limits access even if a forged client certificate header is presented.
• Avoid binding the application to a public route unless required; use Cloud Foundry internal routes like .apps.internal and container-to-container network policies to restrict access to intended internal clients only.

• GitHub Commit
• Maintainer's Advisory