# Lack of ASPNETCORE\_FORWARDEDHEADERS\_ENABLED can lead to http (insecure) URLs in VirtoCommerce Platform **URL:** \ **Category:** howto\ **Created:** [May 15, 2026, 9:38am UTC](https://www.virtocommerce.org/t/lack-of-aspnetcore-forwardedheaders-enabled-can-lead-to-http-insecure-urls-in-virtocommerce-platform/851 "2026-05-15T09:38:36Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![asvishnyakov](https://yyz2.discourse-cdn.com/flex032/user_avatar/www.virtocommerce.org/asvishnyakov/32/2722_2.png) [@asvishnyakov](https://www.virtocommerce.org/u/asvishnyakov)\ **Post date:** [May 15, 2026, 9:38am UTC](https://www.virtocommerce.org/t/lack-of-aspnetcore-forwardedheaders-enabled-can-lead-to-http-insecure-urls-in-virtocommerce-platform/851/1 "2026-05-15T09:38:36Z")
Quick **side story** first: We just identified an issue with our chatbot _VirtoOZ_ - it can’t identify a tenant when the URL has a different scheme (e.g., `http` instead of `https`). The reason is that we compare strictly by origin of the JWT token, which is correct: per the WHATWG URL Standard §3.2, _“An origin is the triple (scheme, host, port). Two origins are equal only if all three components match.”_ The only safe workaround would be an extra request to follow the `http → https` redirect - and we’d need to do that well before any real call to the tenant. That led us to the **root cause**. If ```auto ASPNETCORE_FORWARDEDHEADERS_ENABLED: true ``` **isn’t set** , the platform has **no idea it’s sitting behind an ingress that serves HTTPS** - it assumes plain HTTP. Two things fall out of that: **1. The JWT token issuer ends up with an `http` scheme.** That violates the OIDC spec, which requires `https`. It’s also exactly what tripped VirtoOZ - the issuer origin no longer matches what we have. **2. Every URL built from the platform origin uses `http`.** Links, callbacks, references - all of them pick up an extra redirect hop on the way to the real HTTPS endpoint. We recommend to enable it for every platform deployment in VirtoCloud.