fix : WAF deployment: private backend ingress and frontend proxy rou… by Ashwal-Microsoft · Pull Request #561 · microsoft/content-processing-solution-accelerator

Ashwal-Microsoft · 2026-04-22T20:24:20Z

…ting

Purpose

When enablePrivateNetworking (WAF mode) is active, the backend Container App URL should not be exposed to the browser. This PR adds an application-layer proxy so the browser only communicates with the frontend App Service.

When deploying these accelerators using the WAF deployment option, the expectation is that the backend APIs hosted on Container Apps are secured behind the WAF and are not directly accessible from the public internet. However, the current implementation leaves the Container App API endpoints publicly exposed, which undermines the security posture of the WAF deployment model.

Expected Behavior
The Web App (frontend) should remain publicly accessible through the WAF/Application Gateway.
All backend Container App API endpoints should be private and only accessible internally (e.g., via Container Apps Environment VNet integration, internal ingress, or Private Endpoints).
External users should not be able to directly call the backend Container App API endpoints from outside the network boundary.

Does this introduce a breaking change?

Yes
No

Golden Path Validation

I have tested the primary workflows (the "golden path") to ensure they function correctly without errors.

Deployment Validation

I have validated the deployment process successfully and all services are running as expected with this change.

What to Check

Verify that the following are valid

...

Other Information

…ting

Copilot

Pull request overview

This PR aims to harden the enablePrivateNetworking=true (“WAF mode”) deployment by preventing browsers from calling the backend Container App endpoint directly, instead routing browser API traffic through the frontend container as an application-layer proxy.

Changes:

Add an nginx /api/* reverse proxy in the web container to forward requests to the backend API.
Update infra to make the API ingress internal-only in private networking mode and introduce a private DNS zone for the Container Apps Environment domain.
Update docs to describe the private networking/WAF traffic flow.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/ContentProcessorWeb/nginx-custom.conf	Adds `/api/` reverse-proxying from the web container to the backend API URL.
src/ContentProcessorWeb/env.sh	Extends APP_* placeholder substitution to `/etc/nginx/nginx.conf` so nginx can be templated at runtime.
infra/main.bicep	Switches CAE to internal + disables public network access in private networking mode; makes API ingress internal-only; adds CAE private DNS zone; updates web env vars for `/api` base URL.
infra/main_custom.bicep	Same as `infra/main.bicep` for the custom deployment template.
docs/TechnicalArchitecture.md	Documents the `/api` proxy behavior for private networking deployments.
docs/DeploymentGuide.md	Documents the expected networking posture and proxying behavior in WAF/private networking deployments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-22T20:33:19Z

+        # Route browser API calls through the web container so private backend
+        # endpoints remain internal-only in WAF/private networking deployments.
+        location /api/ {
+            proxy_http_version 1.1;
+            proxy_set_header Host $host;
+            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+            proxy_set_header X-Forwarded-Proto $scheme;
+            proxy_set_header Upgrade $http_upgrade;
+            proxy_set_header Connection "upgrade";
+            proxy_pass APP_BACKEND_API_URL/;
+        }


location /api/ relies on proxy_pass APP_BACKEND_API_URL/; being substituted at runtime. If APP_BACKEND_API_URL is not set in the container environment, env.sh will not replace the placeholder and nginx will fail to start due to an invalid proxy_pass URL. Ensure all deployment paths that run this image always set APP_BACKEND_API_URL (even when the app is not using the /api proxy), or adjust the nginx config/entrypoint to provide a safe default when the variable is missing.

Copilot · 2026-04-22T20:33:20Z

+    publicNetworkAccess: enablePrivateNetworking ? 'Disabled' : 'Enabled'
+    internal: enablePrivateNetworking ? true : false


Setting the Container Apps Environment to internal: true and publicNetworkAccess: 'Disabled' means the environment (and therefore the web Container App inside it) will be reachable only within the VNet. This conflicts with the template still configuring the web Container App ingress as external (ingressExternal: true later in this file). Either keep the environment external and make only the API app's ingress internal, or also make the web app ingress/internal routing consistent with an internal environment (and document the required WAF/App Gateway in front).

Suggested change

publicNetworkAccess: enablePrivateNetworking ? 'Disabled' : 'Enabled'

internal: enablePrivateNetworking ? true : false

publicNetworkAccess: 'Enabled'

internal: false

Copilot · 2026-04-22T20:33:20Z

      ]
    }
-    ingressExternal: true
+    ingressExternal: enablePrivateNetworking ? false : true


With ingressExternal set to false in private networking mode, the API Container App FQDN will no longer be reachable from outside the VNet. The repo's post-deployment scripts currently use CONTAINER_API_APP_FQDN to wait for readiness and register schemas from the deployer's machine; that flow will fail for enablePrivateNetworking=true. Consider updating the post-deployment workflow to call the API through the web app's new /api proxy (using CONTAINER_WEB_APP_FQDN) or to execute the registration from within the VNet (e.g., via the jumpbox).

Suggested change

ingressExternal: enablePrivateNetworking ? false : true

ingressExternal: true

Copilot · 2026-04-22T20:33:21Z

+    publicNetworkAccess: enablePrivateNetworking ? 'Disabled' : 'Enabled'
+    internal: enablePrivateNetworking ? true : false


Setting the Container Apps Environment to internal: true and publicNetworkAccess: 'Disabled' means the environment (and therefore the web Container App inside it) will be reachable only within the VNet. This conflicts with the template still configuring the web Container App ingress as external (ingressExternal: true later in this file). Either keep the environment external and make only the API app's ingress internal, or also make the web app ingress/internal routing consistent with an internal environment (and document the required WAF/App Gateway in front).

Suggested change

publicNetworkAccess: enablePrivateNetworking ? 'Disabled' : 'Enabled'

internal: enablePrivateNetworking ? true : false

publicNetworkAccess: 'Enabled'

internal: false

Copilot · 2026-04-22T20:33:21Z

      ]
    }
-    ingressExternal: true
+    ingressExternal: enablePrivateNetworking ? false : true


With ingressExternal set to false in private networking mode, the API Container App FQDN will no longer be reachable from outside the VNet. The repo's post-deployment scripts currently use CONTAINER_API_APP_FQDN to wait for readiness and register schemas from the deployer's machine; that flow will fail for enablePrivateNetworking=true. Consider updating the post-deployment workflow to call the API through the web app's new /api proxy (using CONTAINER_WEB_APP_FQDN) or to execute the registration from within the VNet (e.g., via the jumpbox).

Suggested change

ingressExternal: enablePrivateNetworking ? false : true

ingressExternal: true

Harden WAF deployment: private backend ingress and frontend proxy rou…

6bb94a0

…ting

Ashwal-Microsoft requested a review from Copilot April 22, 2026 20:24

Ashwal-Microsoft requested review from Avijit-Microsoft, Prajwal-Microsoft, Roopan-Microsoft, Vinay-Microsoft, aniaroramsft, dgp10801, nchandhi and toherman-msft as code owners April 22, 2026 20:24

Ashwal-Microsoft temporarily deployed to production April 22, 2026 20:24 — with GitHub Actions Inactive

Copilot started reviewing on behalf of Ashwal-Microsoft April 22, 2026 20:24 View session

Copilot AI reviewed Apr 22, 2026

View reviewed changes

Update infra Bicep templates and parameters

1fd18c7

Ashwal-Microsoft temporarily deployed to production April 23, 2026 06:22 — with GitHub Actions Inactive

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix : WAF deployment: private backend ingress and frontend proxy rou…#561

fix : WAF deployment: private backend ingress and frontend proxy rou…#561
Ashwal-Microsoft wants to merge 2 commits intodevfrom
waf-private-backend-20260423

Ashwal-Microsoft commented Apr 22, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 22, 2026

Uh oh!

Copilot AI Apr 22, 2026

Uh oh!

Copilot AI Apr 22, 2026

Uh oh!

Copilot AI Apr 22, 2026

Uh oh!

Copilot AI Apr 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		publicNetworkAccess: enablePrivateNetworking ? 'Disabled' : 'Enabled'
		internal: enablePrivateNetworking ? true : false

	ingressExternal: enablePrivateNetworking ? false : true
	ingressExternal: true

Conversation

Ashwal-Microsoft commented Apr 22, 2026

Purpose

Does this introduce a breaking change?

Golden Path Validation

Deployment Validation

What to Check

Other Information

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants