What can a compromised web gateway still reach?

Suppose the gateway host is compromised while its certificate is still valid. Every rule that governed which pages a visitor could request stays in force, and none of those rules constrains the connection the attacker now opens from that host towards the database subnet. That gap is why a web-only entry point is not the same claim as a segmented network. The two claims need separate reviews, from different starting points, before either one can be made honestly.

Two claims, and only one of them starts at the visitor

The first claim is about a person: a visitor with a browser and a valid session can open one application and nothing else. A web-only entry point answers that claim well, because the visitor receives a page rather than a route. That answer is worth having, and it is also the only claim most diagrams record.

The second claim is about a component: the gateway, or the application process behind it, is assumed to be under someone else's control. From that assumption the question changes from which URLs are allowed to which destinations and identities the process can still reach.

The two claims have different owners, produce different evidence, and fail independently. An identity team can demonstrate the first with a session test; the second needs network policy, a service-account review and host controls. A design that records only the visitor half looks complete on a review slide and thin during an incident, because the controls that matter after a compromise were never in scope. Name which claim each control supports, or one gateway rule will be credited with both.

A worked expenses service, and the two ways it loses

Take an expenses service: a public gateway at 10.60.4.10 authenticates staff and forwards approved requests to an application listener on port 8443, and that application reaches one PostgreSQL listener at 10.60.4.20:5432 as the role expenses_app. Employees are not meant to receive general internal access. Under normal operation the design does deliver an application-specific entry without publishing the database listener anywhere. The addresses matter, because every check later in this article names them.

Now remove the gateway from the trusted set. Which destinations can 10.60.4.10 reach once its process belongs to an attacker? The URL filter that constrained visitors says nothing about a connection the gateway host opens towards the database subnet.

Remove the application process instead, and the authority changes shape: the role expenses_app, the services that server can reach, and the files that account can read. In both cases the front door can stay web-only while the backend boundary is absent. The label on the front door is therefore not an answer to either question.

Map the authority each party actually holds

A contract written as intended permissions tends to repeat the design back to you. Write it as held authority, the check that disproves the excess, and the owner of that check, and each row becomes testable. This table is a proposal for the example above, not a product claim:

Ownership follows the authority. The identity team owns assertions, the network platform team owns paths, the application team owns the database role, the database administrator owns the listener and its host-based rules, and the platform owner owns the management plane. A denial with no owner is a sentence in a document rather than a control.

The split also prevents double counting. A port restriction cannot express a table privilege, and a database role cannot stop a host opening a socket to an unrelated subnet.

Enumerate what the gateway can reach instead of asserting it

A boundary claim is only as good as the enumeration behind it. On the gateway host, three commands cover route selection, a live probe and the egress policy:

ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter output

Read the output in that order. The route says whether 10.60.4.20 is even selected from that host; the probe says whether the listener answers; the rule listing shows whether policy stops the packet or whether nothing was ever in its path.

Repeat the enumeration from the application host. From there the database side is one query run as the application role:

psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'

A successful connection under a role that cannot read another schema is a different result from a successful connection under an owner role. Only the second one is a finding.

Record the denials, then date the review

Acceptance is written as outcomes rather than intentions: an employee session cannot reach the listener, the gateway host cannot reach an unrelated subnet, and the application role cannot create a database. Each is a separate check with a named owner and a date.

Keep monitoring, patching and recovery reachable through the management path designed for them. A boundary that also blocks its owner becomes an outage, and the usual first response to that outage is to widen the rule again. The CISA perimeter guidance asks for inbound and outbound access limited to justified ports and protocols, including traffic between internal networks, which is the backend-initiated direction most diagrams leave out.

Date the review and name its owner. Re-run the enumeration and the privilege query after any change to the gateway image, the routing table or the application role.