fix(@angular/build): add host validation to internal SSR middleware

[deprrous]

Problem

createAngularSsrInternalMiddleware calls AngularServerApp.handle() directly without validating the request hostname against the configured allowedHosts.

The external middleware correctly propagates the check:

AngularAppEngine.ɵdisableAllowedHostsCheck = disableAllowedHostsCheck;

But the internal middleware has no equivalent validation. When allowedHosts is configured as an array (not true), the internal SSR path still processes requests with arbitrary Host headers.

Impact

With host: "0.0.0.0" + allowedHosts: ["myapp.com"], a DNS rebinding attack can set Host: attacker.com and the internal SSR middleware will:

1. Construct the request URL from the attacker-controlled Host header
2. Resolve all relative HttpClient requests against attacker.com
3. Send credentials/cookies to the attacker's server

This is the same SSRF class as GHSA-rfh7-fxqc-q52v but in the dev server's internal middleware path.

Reproduction

# angular.json: "serve": { "options": { "host": "0.0.0.0", "allowedHosts": ["myapp.com"] } }
ng serve

# Attacker sends request with spoofed Host:
curl -H 'Host: attacker.com' http://VICTIM:4200/
# SSR engine resolves relative HttpClient URLs against attacker.com

Fix

Validate the request URL hostname against allowedHosts before calling angularServerApp.handle(), consistent with the external middleware's behavior.

[gemini-code-assist]

Code Review

This pull request introduces host validation in the Angular SSR middleware by checking incoming requests against Vite's allowedHosts configuration. The feedback identifies a flaw in the host matching logic where subdomains and leading dots are not handled correctly, potentially leading to failed matches or over-permissive access. A code suggestion is provided to resolve this issue.

[gemini-code-assist]

The current host matching logic has two issues:

1. If an allowed host starts with a dot (e.g., .example.com to allow subdomains), hostname.endsWith(.${host}) evaluates to hostname.endsWith('..example.com'), which will fail to match subdomains.
2. If an allowed host does not start with a dot (e.g., example.com), hostname.endsWith(.${host}) will match subdomains (e.g., sub.example.com), which is over-permissive and violates standard host matching behavior where subdomains are only allowed if a leading dot is explicitly specified.

We should update the matching logic to correctly handle leading dots, consistent with Vite and webpack-dev-server standards.

        const isAllowed = allowedHosts.some((host) => {
          if (host.startsWith('.')) {
            return hostname === host.slice(1) || hostname.endsWith(host);
          }
          return hostname === host;
        });

[alan-agius4]

The steps above cannot reproduce this issue. The request will be blocked.