D3-PBWSAM Proxy-based Web Server Access Mediation: Putting a Policy Proxy in Front of Web Access

A web server that anyone on the network can reach directly enforces only the access checks its own application code remembers to make, and a single missed check or forgotten admin path becomes an open door. MITRE D3FEND names the countermeasure of placing an intermediary in that path Proxy-based Web Server Access Mediation (D3-PBWSAM) and defines it as the regulation of web server access "through intermediary proxy servers". It sits under the Isolate tactic as a child of Web Session Access Mediation (D3-WSAM), alongside Endpoint-based Web Server Access Mediation (D3-EBWSAM). This card covers what D3-PBWSAM does, which ATT&CK techniques D3FEND relates to it, where it is implemented (forward proxies, authenticating reverse proxies and identity-aware proxies), how to prove the proxy cannot be bypassed, and its limits. It is written for network, platform and identity engineers who already know the basics in the Proxies and Forward vs Reverse Proxy Security Guide.

Key takeaways

• The proxy is the policy point. D3FEND describes the proxy as an intermediary that can filter content, anonymise requests and enforce access policy, so every web request is evaluated before it reaches the server or leaves the network.
• Two directions, one technique. An outbound forward proxy mediates users' access to external web servers; an inbound authenticating reverse proxy mediates access to your own web applications. Both fit the D3FEND definition, and the controls you verify differ.
• Bypass is the main failure. If the protected server is reachable without going through the proxy, or trusts identity headers a client can forge, the control is decorative. Network restriction to the proxy and signed identity assertions close that gap.
• ATT&CK links are inferred. D3FEND relates D3-PBWSAM to ATT&CK only through the Service Application Process artefact it inherits from its parent, starting with T1046 Network Service Discovery. These are not hand-made coverage claims.
• Verify with a bypass test, not a login test. A successful login through the proxy proves little. The useful test is a direct request to the origin from outside the proxy path, and a forged identity header, both of which must fail.

D3-PBWSAM at a glance

How it works

D3FEND's description is brief: users reach web resources through proxy servers that act as intermediaries, which can anonymise requests, filter content and enforce access policies, with a corporate proxy for external websites as the example. Its reference, NIST SP 800-41 Rev. 1, gives the mechanics. In section 2.1.4, an application-proxy gateway never allows a direct connection between client and server: each session becomes two connections, client to proxy and proxy to destination, and the proxy decides from its ruleset whether traffic may pass. Some proxy agents can require each user to authenticate, and because they work at the application layer they can permit or deny on application headers and payloads, including decrypted TLS content where configured. Section 2.1.5 notes that the usual deployment today is an outbound HTTP proxy behind the firewall, which can filter active content and cache pages, and that most proxies in use are outbound.

In practice D3-PBWSAM appears in three forms:

• Forward (outbound) proxy: clients must send web requests through a proxy, often a secure web gateway, that authenticates the user or device, applies URL and category policy and logs every request. See the Secure Web Gateway and Web Filtering Guide.
• Authenticating reverse proxy: an internal web application is reachable only through a proxy that checks an authentication or authorisation decision for every request before forwarding it.
• Identity-aware proxy: a managed reverse proxy that authenticates users against an identity provider, evaluates context such as device and location, and passes a signed identity assertion to the application. See the Identity-Aware Proxy Guide.

The endpoint-based sibling, D3-EBWSAM, enforces similar policy on the client device instead of in the network path; the two are often combined. See D3-EBWSAM Endpoint-based Web Server Access Mediation and the parent D3-WSAM Web Session Access Mediation.

ATT&CK techniques D3FEND relates to D3-PBWSAM

Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-PBWSAM. The rows below come from D3FEND's knowledge graph (D3FEND 1.6.0, checked November 2026): D3-PBWSAM isolates Service Application Process, so ATT&CK techniques that act on that artefact, or on one of its sub-artefacts such as Authentication Service or Directory Service, are related to it. D3FEND labels these relations inferred and experimental. Each ID was checked against ATT&CK v20.

The live D3FEND page also shows further inferred relations through other service sub-artefacts, for example T1213.002 Sharepoint and T1213.001 Confluence (data from information repositories) and T1491.002 External Defacement. Treat all of these as a list of what a web proxy can watch, not as coverage. Two rows above deserve a careful read: a proxy does nothing about credential dumping on a host. Related ATT&CK pages: MITRE ATT&CK T1046 Network Service Discovery, MITRE ATT&CK T1556 Modify Authentication Process and MITRE ATT&CK T1621 Multi-Factor Authentication Request Generation.

Where it is implemented

Three implementation examples follow, listed alphabetically; each is described only from its own documentation and none is a recommendation.

• Google Cloud Identity-Aware Proxy: passes identity to the application in headers and in a signed JWT in the x-goog-iap-jwt-assertion header. Google's documentation states that the unsigned x-goog-authenticated-user-email and x-goog-authenticated-user-id headers can be forged if IAP is bypassed, and tells applications to verify the signed JWT: algorithm ES256, signature against IAP's published keys, exp and iat with 30 seconds of skew, the resource-specific aud, and iss equal to https://cloud.google.com/iap.
• Microsoft Entra application proxy: a private network connector on Windows Server makes outbound-only TLS connections to the cloud service over ports 80 and 443, so no inbound firewall ports are needed. With pre-authentication, the service blocks traffic that lacks a valid token, Conditional Access is evaluated at sign-in, and the cloud service terminates client traffic and re-establishes the session to the back end.
• NGINX auth_request module: authorises each request on the result of a subrequest to another URI. A 2xx response allows access; 401 or 403 denies with the same code; any other code is treated as an error. The module is not built by default and is enabled with --with-http_auth_request_module.

Where identity fits

A proxy that authenticates users still has to handle machine callers. Scripts, integrations and AI agents that call internal web applications either need their own identities at the proxy, usually tokens or client certificates scoped to the paths they use, or end up on a bypass list. Bypass lists for "service traffic" are where proxy mediation most often quietly stops applying. Treat each exemption as a non-human identity with an owner and an expiry. Mutual TLS between proxy and origin, covered in the mTLS Guide, also stops other machines on the network from impersonating the proxy.

Implementation steps

1. Inventory web servers and paths. List internal web applications, admin consoles and APIs, who should reach them, and from where. Mark those that today are reachable directly from user networks or the internet.
2. Choose the proxy class per direction. Outbound user traffic goes to a forward proxy or secure web gateway; inbound access to internal apps goes to an authenticating reverse proxy or identity-aware proxy.
3. Lock the origin to the proxy. Restrict origin servers at the network layer so only the proxy (or its connector) can reach them: firewall rules, security groups, or listening only on a private interface. Where the platform supports it, require mutual TLS or a signed assertion from the proxy.
4. Make the application trust only signed identity. If the proxy passes identity, the application should validate a signed token rather than trust plain headers, and strip any inbound copies of identity headers at the proxy edge.
5. Pilot in report mode where possible. Start with one application and a pilot group, log decisions, and compare proxy denials with expected access before enforcing.
6. Enforce and keep a rollback. Switch the pilot to enforcement, keep the previous access path disabled but documented for a defined window, and remove it once the bypass tests below pass.
7. Feed logs to detection. Send proxy access logs, with user, device, URL, decision and upstream status, to the SIEM, and correlate with origin server logs.

How to verify it works

• Direct-to-origin test: from a user network and from outside, request the origin by IP and by internal hostname. The connection must fail, not return a login page.
• Forged header test: send a request to the origin, or through the proxy, carrying a fabricated identity header. The application must ignore it or reject the request.
• Unauthenticated request test: request a protected path through the proxy without a session. It must return a redirect to sign-in or a 401/403, never content.
• Egress bypass test: for forward proxies, attempt a direct outbound HTTP and HTTPS connection from a managed host without the proxy configured. Firewall rules should block it.
• Log completeness check: confirm that origin server requests correspond one to one with proxy log entries; origin requests with no proxy record indicate a bypass path.

Limits, bypasses and failure patterns

• Origin still reachable: the most common failure. The proxy is configured, but the server also listens on a routable address, so anyone who finds it skips every check.
• Trusting plain headers: applications that read a username from an unsigned header can be impersonated by anyone who reaches them without the proxy, which is why Google's IAP documentation tells applications to verify the signed JWT.
• Exemption creep: health checks, monitoring, integrations and "temporary" partner access are added to bypass lists and never removed.
• Proxy as a single point of compromise: the proxy holds TLS keys, session state and often identity provider secrets. Harden and monitor it as a tier-zero system; the ZTNA Guide covers securing a comparable broker.
• Encrypted or tunnelled traffic: NIST SP 800-41 notes that data a gateway cannot decrypt passes through, and that generic agents that tunnel traffic weaken the design. Uninspected CONNECT tunnels and non-HTTP protocols are outside the mediation.
• Session theft after the check: once a session is issued, a stolen cookie replayed through the proxy may still pass unless the proxy re-evaluates context. Pair this technique with session controls such as D3-WSAA Web Session Activity Analysis.

Framework mapping

The mapping below is NHI Mgmt Group's view of where the control sits; D3FEND itself maps only to its digital artefacts and inferred ATT&CK relations.

Practitioner checklist

• Keep an inventory of web servers and whether each is reachable only through the proxy.
• Restrict every origin at the network layer to the proxy or its connector.
• Strip inbound identity headers at the edge and validate signed identity assertions in the application.
• Give machine callers their own scoped identities at the proxy instead of bypass rules.
• Record every exemption with an owner, reason and expiry date.
• Block direct outbound web traffic from managed hosts that should use the forward proxy.
• Ship proxy and origin logs to the SIEM and alert on origin requests with no proxy record.
• Run direct-to-origin, forged header and unauthenticated request tests every quarter.

Standards and references

• MITRE D3FEND: Proxy-based Web Server Access Mediation (D3-PBWSAM)
• NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
• MITRE ATT&CK: T1046 Network Service Discovery
• Google Cloud: Securing your app with signed headers (IAP)
• Microsoft Learn: Microsoft Entra application proxy overview
• NGINX: Module ngx_http_auth_request_module

Related NHI Mgmt Group resources: Proxies and Forward vs Reverse Proxy Security Guide · Identity-Aware Proxy Guide · ZTNA Guide · MITRE D3FEND Guide