IBX-11181: Trusted Proxies is not set on Ibexa Cloud by vidarl · Pull Request #699 · ibexa/core

vidarl · 2026-01-14T13:55:07Z

🎫 Issue	IBX-11181

Related PRs:

PR for filtering X-Forward-For in varnish and fastly VCLs are comming

Description:

Trusted proxies are not set on Ibexa Cloud when using Fastly. We document (via Upsun,) that user must disable TRUSTED_PROXIES: "REMOTE_ADDR" in .platform.app.yaml (which is correct), but we don’t say or specify how to configure TRUSTED_PROXIES correctly.

And frankly, it is not easy/possible to do via static config given how the Upsun router behaves:

Upsun router behavior:

Will not filter X-FORWARD-FOR sent by malicious client
It will add client's IP to X-FORWARD-FOR, appending header if already set ( "1.1.1.1" => "1.1.1.1, 2.2.2.2")
It will always set a X-Client-IP header ( value is IP of client). Value is also end-user's IP if request is received via Fastly ( doc )
Will filter Client-Cdn if request is not originating from any supported CDN ( doc )
- When received from Fastly, value of header will be fastly
$_SERVER['REMOTE_ADDR'] will be spoofed, will have same value as X-Client-IP

So there is no static IP or IP range you can set as trusted proxies when using Fastly on Upsun. For instance, setting trusted hosts to Fasty's public IP list will not do any good. Thus, Ibexa DXP should automatically detect on Ibexa Cloud if request is received via Fastly

Next, I really doesn't understand the original purpose of TrustedHeaderClientIpEventSubscriber. It basically does this:

If running on Upsun (formerly known as Platform.sh), the request header X_FORWARDED_FOR will be set (value will be copied from the X-Client-IP request header) and X_FORWARDED_FOR will be set as trusted_headers
However, this header will still be ignored unless devs somehow also sets trusted_proxies correctly.
Also, the subscriber can be configured to use some other header than X-Client-IP as source

My next doubt is why there was some need for this in relation to IBX-4046
FYI : Original PR : https://github.com/ibexa/core/pull/165/files

As the Upsun router anyway sets the X-Forward-For header, and devs still needed to set trusted_proxies in config ( which IMO is impossible), the old implementation in TrustedHeaderClientIpEventSubscriber is void.
But it certainly may be that I am missing something important....?

What the new implementation of TrustedHeaderClientIpEventSubscriber does:

If we are on Ibexa Cloud and request is coming from Fastly, then we declare that the request is received via trusted proxy

For QA:

Maybe do sanity checks with "create Applications for Customer portal" feature, as original implementation of TrustedHeaderClientIpEventSubscriber was implemented in relation to that.

Documentation:

vidarl · 2026-01-14T14:29:05Z

@@ -15,16 +15,6 @@

 final class TrustedHeaderClientIpEventSubscriber implements EventSubscriberInterface


Suggested change

final class TrustedHeaderClientIpEventSubscriber implements EventSubscriberInterface

final class IbexaCloudTrustedProxiesEventSubscriber implements EventSubscriberInterface

Or this is considered a BC ? Class is final though, so maybe not a problem?

We don't care

isnt IbexaCloud too generic tho? this whole class is about Upsun & Fastly, right?

@ViniTou IbexaCloud is on Upsun, and only there. We could call it FastlyOnIbexaCloudTrustedProxiesEventSubscriber or something if you like? Personally, I prefer IbexaCloudTrustedProxiesEventSubscriber though

sonarqubecloud · 2026-01-19T14:51:57Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

sonarqubecloud · 2026-07-30T10:54:59Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

konradoboza

PR can be rebased as #794 got merged, it contains PHPStan issues fix.

A few questions:

PR for filtering X-Forward-For in varnish and fastly VCLs are comming

Do we have this PR already? It should most likely incorporate X-Forward-For and X-Forward-Host in our VCL, right?

Shouldn't this indeed belong to ibexa/fastly since it's covering this very case? It will also make more sense concerning merging up the changes.

In regards to:

As the Upsun router anyway sets the X-Forward-For header, and devs still needed to set trusted_proxies in config ( which IMO is impossible), the old implementation in TrustedHeaderClientIpEventSubscriber is void.
But it certainly may be that I am missing something important....?

https://github.com/ibexa/post-install/blob/4.6/resources/platformsh/ibexa-commerce/4.6/.platform.app.yaml#L65 I think this is where it can be omitted once projects are created from templates. This seems like potential security flaw where XFF remains untouched. The subscriber in question overwrites XFF (attacker-influenced?) with X-Client-IP (router-controlled) so that the processing reads a clean value.

It seems we need to do the following to summarize:

sunset ibexa/fastly-forwarded-host (archive),
make sure VCL is properly updated,
the combo mentioned below is verified not to fallback to the Symfony defaults.

konradoboza · 2026-07-31T09:42:35Z

-        if (null === $trustedHeaderName && $this->isPlatformShProxy($request)) {
-            $trustedHeaderName = self::PLATFORM_SH_TRUSTED_HEADER_CLIENT_IP;
+        if ($this->isPlatformShProxy($request) && $request->headers->get('Client-Cdn') === 'fastly') {
+            Request::setTrustedProxies(['REMOTE_ADDR'], Request::getTrustedHeaderSet());


Wouldn't that fallback to Symfony's default if framework.trusted_proxies was never set? Shouldn't we be more specific here by passing: HEADER_X_FORWARDED_FOR | HEADER_X_FORWARDED_HOST | HEADER_X_FORWARDED_PROTO | HEADER_X_FORWARDED_PORT combo?

Via Symfony's code:

$trustedHeaderSet = $trustedHeaders ?? (Request::HEADER_X_FORWARDED_FOR | Request::HEADER_X_FORWARDED_PORT | Request::HEADER_X_FORWARDED_PROTO);

Host and Prefix are omitted in this case but the question is - do we really need them? It's not like previous Subscriber added Host so imo this change is proper. Subscriber didn't pass Host and we aren't passing Host now.

Host has the following note in Symfony docs:

Enabling the Request::HEADER_X_FORWARDED_HOST option exposes the application to [HTTP Host header attacks](https://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html). Make sure the proxy really sends an x-forwarded-host header.

On the other hand, HOST was set manually in https://github.com/ibexa/fastly-forwarded-host/blob/main/src/bundle/EventSubscriber/KernelRequestSubscriber.php and if we are deprecating this bundle I would say we also need to pass X_FORWARDED_HOST explicitly? I believe we can pass it safely because proxy sends it safely and cannot be spoofed due to Client-Cdn existance that guarantess request is actually coming from proxy?

Additionally, if I understand correctly fastly-forwarded-host bundle was created some time ago because of the need to handle a lot of Upsun domains and overcome some routing (??) limitations. Perhaps the FORWARDED-HOST should be enabled explicitly in this subscriber via a dedicated config option if such a limitation occurs?

The previous implementation enabled X_FORWARDED_FOR as a trusted header. But it did not change $trustedProxies ( the actually IPs that where trusted ) and there was no way to configure that requests coming from Fastly should be trusted (because of the spoofing of the IP that takes place on Upsun).
So AFAIK, this subscriber didn't really change the behavior in any way, ie: adding X_FORWARDED_FOR as trusted header had no effect what-so-ever.

With my change, the requests is now trusted if it comes via Fastly. My idea was this simply that this enables site integrators to enable the trusted headers they need - it makes that part possible. Then it is up to site integrators to decide what headers to enable.

We could of course make things more convenient and add some default trusted headers. But this should then be treated as BC and be documented IMO.

github-actions Bot assigned alongosz, tischsoic and mikadamczyk Jan 14, 2026

vidarl changed the base branch from main to 4.6 January 14, 2026 13:57

vidarl force-pushed the IBX-11181-Trusted_Proxies_is_not_set_on_Ibexa_Cloud branch from 38c87b6 to 17e4096 Compare January 14, 2026 14:00

vidarl commented Jan 14, 2026

View reviewed changes

vidarl force-pushed the IBX-11181-Trusted_Proxies_is_not_set_on_Ibexa_Cloud branch from 17e4096 to b1a199d Compare January 14, 2026 14:37

vidarl requested a review from a team January 19, 2026 15:03

vidarl added the Ready for review label Jan 19, 2026

ibexa-workflow-automation-1 Bot requested review from Steveb-p, ViniTou, alongosz, barw4, ciastektk, konradoboza, mikadamczyk, tbialcz and wiewiurdp and removed request for a team January 19, 2026 15:03

vidarl added 2 commits July 30, 2026 09:30

IBX-11181: Trusted Proxies is not set on Ibexa Cloud

cb8e4b2

Fixed tests

d53633c

vidarl force-pushed the IBX-11181-Trusted_Proxies_is_not_set_on_Ibexa_Cloud branch from ec3cba0 to d53633c Compare July 30, 2026 07:31

barw4 reviewed Jul 30, 2026

View reviewed changes

Comment thread src/bundle/Core/EventSubscriber/TrustedHeaderClientIpEventSubscriber.php

IBX-11181: PHPStan

8e6ec00

barw4 approved these changes Jul 30, 2026

View reviewed changes

konradoboza reviewed Jul 31, 2026

View reviewed changes

		@@ -15,16 +15,6 @@

		final class TrustedHeaderClientIpEventSubscriber implements EventSubscriberInterface

	final class TrustedHeaderClientIpEventSubscriber implements EventSubscriberInterface
	final class IbexaCloudTrustedProxiesEventSubscriber implements EventSubscriberInterface

Uh oh!

Conversation

vidarl commented Jan 14, 2026 • edited by atlassian Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Related PRs:

Description:

For QA:

Documentation:

Uh oh!

vidarl Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

barw4 Jul 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ViniTou Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vidarl Aug 3, 2026

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud Bot commented Jan 19, 2026

Quality Gate passed

Uh oh!

Uh oh!

sonarqubecloud Bot commented Jul 30, 2026

Quality Gate passed

Uh oh!

konradoboza left a comment

Choose a reason for hiding this comment

Uh oh!

konradoboza Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

barw4 Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

barw4 Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

barw4 Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vidarl Aug 3, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

vidarl commented Jan 14, 2026 •

edited by atlassian Bot

Loading

vidarl Jan 14, 2026 •

edited

Loading

barw4 Jul 30, 2026 •

edited

Loading

ViniTou Jul 31, 2026 •

edited

Loading

barw4 Jul 31, 2026 •

edited

Loading

barw4 Jul 31, 2026 •

edited

Loading

barw4 Jul 31, 2026 •

edited

Loading