security.allowedDomains with protocol breaks X-Forwarded-Proto validation in 5.17.2

[z0mt3c]

Astro Info

Astro                    v5.17.2
Node                     v22.x
System                   Linux (Docker, behind Traefik reverse proxy)
Package Manager          pnpm
Output                   server
Adapter                  @astrojs/node (v9.5.3)

If this issue only occurs in one browser, which browser is a problem?

Not browser-specific. Reproducible via curl.

Describe the Bug

When security.allowedDomains includes a protocol field, the X-Forwarded-Proto header is silently rejected, causing Astro.url to use http:// instead of https://.

This is a regression introduced in 5.17.2 via commit c13b536 ("Validate Host header against allowedDomains"), which was the fix for #14891.

Config:

export default defineConfig({
  output: 'server',
  adapter: node({ mode: 'standalone' }),
  security: {
    allowedDomains: [{ hostname: 'example.com', protocol: 'https' }],
  },
})

Headers sent by reverse proxy (i my case Traefik):

Host: example.com
X-Forwarded-Host: example.com
X-Forwarded-Proto: https
X-Forwarded-Port: 443

Result: Astro.url = http://example.com/... (protocol is http, not https)

Workaround: Remove protocol from the pattern:

allowedDomains: [{ hostname: 'example.com' }]

What's the expected result?

When allowedDomains is [{ hostname: 'example.com', protocol: 'https' }] and the proxy sends X-Forwarded-Proto: https, Astro.url.protocol should be https:.

Link to Minimal Reproducible Example

unavailable, setup complicated

Participation

• I am willing to submit a pull request for this issue.

[astrobot-houston]

I was able to reproduce this issue. The root cause is in packages/astro/src/core/app/validate-headers.ts — the validateForwardedHeaders function validates X-Forwarded-Proto by constructing a test URL with a hardcoded dummy hostname "example.com" and then calling matchPattern, which checks all pattern fields (hostname, protocol, port, pathname). When the user's allowedDomains pattern has any hostname other than literally "example.com", the hostname check fails and the valid forwarded protocol is silently rejected, causing Astro.url to fall back to http://. Existing tests didn't catch this because they all coincidentally use hostname: 'example.com' in patterns that include a protocol field.

Fix: I was able to fix this issue. The fix replaces the matchPattern-based protocol validation with a direct protocol field comparison (pattern.protocol === forwardedProtocol), consistent with how port validation is already done on the same file. A ^https?$ regex guard preserves the security properties previously handled by the try/catch around new URL(). Two new regression tests were added. All 40 unit tests pass (38 existing + 2 new) with no regressions. View Suggested Fix

Priority: [P4: important]. This bug silently breaks Astro.url.protocol for any user running behind a reverse proxy (a very common production setup) who includes protocol in their security.allowedDomains configuration. Since the allowedDomains docs accept protocol as a valid field, users following the documentation are likely to hit this. The workaround (removing protocol from the pattern) is simple, but discovering it requires significant debugging since the protocol rejection is silent with no warnings or errors.

Full Triage Report

Triage Report: Issue #15559

Issue Summary

Title: security.allowedDomains with protocol breaks X-Forwarded-Proto validation in 5.17.2

Author: z0mt3c

URL: #15559

Description: When security.allowedDomains includes a protocol field, the X-Forwarded-Proto header is silently rejected, causing Astro.url to use http:// instead of https://. The reporter states this is a regression from commit c13b536 ("Validate Host header against allowedDomains"), which was the fix for issue #14891.

Config that triggers the bug:

export default defineConfig({
  output: 'server',
  adapter: node({ mode: 'standalone' }),
  security: {
    allowedDomains: [{ hostname: 'example.com', protocol: 'https' }],
  },
})

Headers sent by reverse proxy:

Host: example.com
X-Forwarded-Host: example.com
X-Forwarded-Proto: https
X-Forwarded-Port: 443

Expected: Astro.url should have https: protocol
Actual: Astro.url has http: protocol — the forwarded protocol is silently rejected

Workaround: Remove protocol from the pattern: allowedDomains: [{ hostname: 'example.com' }]

Reproduction Status: REPRODUCED ✓

Reproduction Steps

1. Created a minimal Astro project with @astrojs/node adapter in standalone mode
2. Configured security.allowedDomains with [{ hostname: 'myapp.example.com', protocol: 'https' }]
3. Created a page that outputs Astro.url.toString(), Astro.url.protocol, and Astro.url.hostname
4. Built and started the server
5. Made a curl request simulating a reverse proxy with X-Forwarded-Proto: https

Result with protocol in allowedDomains: URL: http://myapp.example.com/ — protocol incorrectly http:
Result without protocol (workaround): URL: https://myapp.example.com/ — protocol correctly https:

Root Cause Analysis (Confirmed via Instrumentation)

File: packages/astro/src/core/app/validate-headers.ts, lines 94-96

The validateForwardedHeaders function validates X-Forwarded-Proto by constructing a test URL with a hardcoded dummy hostname "example.com":

const testUrl = new URL(`${forwardedProtocol}://example.com`);
const isAllowed = allowedDomains.some((pattern) => matchPattern(testUrl, pattern));

matchPattern checks all fields of the pattern — hostname, protocol, port, and pathname. When the user's hostname differs from the dummy "example.com", matchHostname fails, causing the valid forwarded protocol to be silently rejected.

Debug instrumentation confirmed:

[DEBUG] testUrl.hostname: example.com
[DEBUG] matchPattern against pattern: {"hostname":"myapp.example.com","protocol":"https"} = false
[DEBUG] isAllowed: false

Why Existing Tests Didn't Catch This

All existing tests that specify protocol: 'https' in allowedDomains patterns coincidentally use hostname: 'example.com' — the same value as the hardcoded dummy. So matchHostname accidentally passes, masking the bug.

Verification: bug (high confidence)

• No comment or rationale for the dummy hostname — it was a convenience shortcut, not deliberate
• Inconsistency: port validation uses direct field comparison, protocol uses matchPattern
• PR Fixes an issue with x-forwarded headers and checkOrigin' #15534 independently confirms the same root cause
• PR Validate Host header against allowedDomains #15473 (the introducing PR) shows no intent for this behavior
• Documentation implies protocol should work in patterns

Fix Applied

Replaced matchPattern-based protocol validation with direct protocol field comparison, consistent with port validation. Added ^https?$ regex guard for security. Two new regression tests added. All 40 tests pass with no regressions. End-to-end verification confirmed Astro.url now correctly uses https:// after the fix.

This report was made by an LLM. Mistakes happen, check important info.