Public endpoints & load balancers
Public endpoints and load balancers are the deliberate front door to your cloud — but they are also where the most surface area accumulates without anyone deciding it should. Every Application Load Balancer listener, API gateway route, static-site endpoint, function URL, and elastic public IP is a place the internet can reach a running service, and each one tends to be created for a single purpose and then quietly outlive it. The failure mode here is not usually a wide-open firewall rule; it is a load balancer that fronts one intended app but also has a listener rule or an extra target group exposing an admin console, a staging build, or an internal API to the whole world. This sub-topic inventories what is genuinely reachable at the edge, confirms each endpoint is meant to be public, and checks that traffic reaching it is authenticated, encrypted, and routed through the protective layers you think are in front of it.
Overview
What this check looks like in practice
Load balancers, API gateways, and public IPs are meant to publish some services — but they routinely publish more than intended, exposing internal APIs, staging environments, and management interfaces to anyone. We inventory what is actually reachable at the edge and compare it to what should be public. The goal is a small, deliberate public surface, with everything else behind private networking.
Why it matters
To an attacker, your public endpoints are the reconnaissance map: they enumerate load balancer DNS names, certificate transparency logs, and IP ranges to find the endpoint you forgot was public, because that is where authentication and monitoring are weakest. A single listener rule fronting an internal admin panel, or an origin server whose public IP still answers directly and bypasses the WAF and CDN, converts a hardened edge into decoration. Endpoints serving over plaintext or with weak TLS expose credentials and session tokens in transit, and an unauthenticated API gateway route leaks data with no exploit required at all. Auditors read this the same way — an inventory of internet-facing services with a documented business justification for each is exactly the evidence PCI-DSS, CIS, and ISO 27001 expect, so a sprawling or undocumented public surface is both a real breach path and an audit finding.
What we assess
What we look for
- Internal, staging, admin, or debug services fronted by internet-facing load balancers, API gateways, or public IPs when they should be private
- Load balancer listeners and listener/routing rules that expose more paths, ports, or target groups than the intended service requires
- Origin servers with public IPs that answer directly, bypassing the CDN, WAF, or reverse proxy the traffic is supposed to pass through
- Endpoints serving over plaintext HTTP, or terminating TLS with weak protocol versions and cipher suites, where encryption should be enforced
- API gateway routes, function URLs, and serverless endpoints that are reachable without authentication or authorization
- Public object-storage website endpoints and CDN distributions serving buckets or origins that were never meant to be published
- Elastic/public IPs and load balancers with no attached workload, stale target groups, or unhealthy targets — abandoned exposure that lingers
- Health-check, actuator, metrics, or management ports (e.g. /actuator, /metrics, admin listeners) reachable through the public endpoint
Across your clouds
AWS, Azure & Google Cloud
AWS
Application and Network Load Balancer listeners, listener rules, and target groups; internet-facing vs. internal ELB scheme; API Gateway (REST/HTTP) routes and authorizers; Lambda function URLs; CloudFront distributions with origin access control (OAC) for S3 and Lambda function URL origins, plus VPC origins for private ALB/NLB/EC2 origins, so origins are not reachable directly; Elastic IPs and public IPv4 addresses; ACM certificates and TLS security policies on listeners; AWS WAF web ACL association.
Azure
Azure Load Balancer (public vs. internal) plus its L4 load-balancing rules; Application Gateway listeners and routing rules with an attached WAF policy; Front Door endpoints; public IP address resources and their associations; API Management gateways, products, and subscription/authentication requirements; Function App and App Service access restrictions; enforcing traffic through Front Door/App Gateway rather than the origin's default *.azurewebsites.net hostname; TLS minimum version and HTTPS-only settings.
Google Cloud
Cloud Load Balancing (external Application and Network load balancers), URL maps, backend services, and forwarding rules; external IP addresses; API Gateway and Cloud Endpoints with API keys/JWT auth; Cloud Run and Cloud Functions ingress settings (all vs. internal-and-cloud-load-balancing only); Cloud Armor security policies attached to backend services; Google-managed SSL certificates and SSL policies (minimum TLS version and profile).
Example finding
Internal admin API exposed through a public ALB listener rule
Risk: A production Application Load Balancer that fronts a customer web app also carries a path-based listener rule routing /admin to an internal management target group, making an unauthenticated admin API reachable from the public internet. Attackers enumerate load balancer hostnames and probe common admin paths automatically, so this endpoint is discoverable within minutes and turns a UI meant for internal operators into a direct, internet-facing control surface.
Fix: Remove the /admin listener rule from the internet-facing load balancer and serve the admin target group only through an internal load balancer reachable over private networking or a bastion/managed access path. Where an internal LB is not viable, require authentication at the edge (an authorizer or identity-aware proxy) and restrict the rule to known source ranges, then confirm the origin cannot be reached directly by its own address.
Remediation
How to close it
- 1 Build an authoritative inventory of every internet-facing endpoint — load balancers, API gateways, function URLs, public IPs, and storage/CDN endpoints — across all accounts, subscriptions, and projects.
- 2 For each endpoint, confirm and document the business reason it is public; retire or make private anything without a current, justified reason to be reachable from the internet.
- 3 Tighten each load balancer to its intended service: prune extra listeners, listener/routing rules, and target groups, and move internal, staging, and admin targets behind internal load balancers or private networking.
- 4 Lock origins so they can only be reached through the intended edge — associate the WAF/Cloud Armor policy, enforce origin access controls, and restrict origins to accept traffic only from the CDN or load balancer.
- 5 Enforce encryption and authentication at the edge: require HTTPS with a modern TLS policy, redirect plaintext, and put an authorizer or identity-aware proxy in front of any API route that is not intentionally anonymous.
- 6 Establish ongoing detection for new public exposure — alert on newly created internet-facing load balancers, public IP assignments, and open listeners — so the surface does not silently regrow after remediation.
Questions
How is this different from just reviewing security groups and firewall rules?
Security groups govern which ports and source ranges are allowed at the network layer; public endpoints and load balancers govern which application services you have deliberately published and how. A security group can be perfectly scoped and you can still expose an internal admin API through a load balancer listener rule or an unauthenticated API route. We review the edge from the application's perspective — what a request actually reaches once it is past the firewall — which is a distinct layer from the packet-level rules.
We use a CDN and WAF — doesn't that already protect our public endpoints?
Only if every request is forced through them. A very common finding is an origin server or storage bucket that still answers on its own public address, so an attacker who resolves the origin simply skips the CDN and WAF entirely. We verify that origins are locked to accept traffic only from the intended edge (via origin access controls, source restrictions, or private origins) so the protective layer cannot be bypassed.
Do you test the endpoints by sending traffic to them?
No. This is a read-only configuration review — we inspect load balancer listeners, routing rules, target groups, gateway routes, TLS policies, and origin settings as recorded in your cloud provider. There is no active probing, penetration testing, or traffic sent to your endpoints, and nothing in production is changed.
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
