We aresecurity engineerswho break bits and tell stories.Visit usdoyensec.comFollow us@doyensecEngage usinfo@doyensec.com © 2026Doyensec LLC After our last episode onMulti-SSO Cognito User Pools, we are back with another issue. This time, we are looking at one of those AWS components that is everywhere and rarely questioned deeply enough: theElastic Load Balancer. AWS Elastic Load Balancing (ELB) distributes traffic to backend services and serves as the entry point between the Internet and your applications. It supports Layer 7 routing (Application Load Balancer - ALB) and Layer 4 routing (Network Load Balancer - NLB). It decideswhere traffic goesandunder which conditions. ELB is commonly found fronting multiple applications, environments, and trust zones across the same infrastructure. ELB is often the first public entry point before application backends, and in many AWS environments, it also becomes part of the access-control boundary. For ALBs, listener rules do more than route traffic: they can enforce authentication withauthenticate-oidcorauthenticate-cognito, restrict access withsource-ipconditions, and decide which target group receives a request based on host, path, headers, or other request attributes. The simplified flow below shows how a single request can be routed through different rules depending on priority and matching conditions: That makes the listener rule chain security-sensitive. A backend may appear protected when looking at a single rule, but still be reachable through another rule, another listener, another ALB, or a direct network path that bypasses the expected entry point. Misconfigurations there could: Standard load balancer reviews usually focus on resource level hygiene: TLS policies, access logging, deletion protection, security groups, and whether a WAF is attached. These checks are useful, but they mostly describe how the load balancer is configured, without an offensive mindset. They do not answer the important question:what can an external request actually reach? What usually gets missed during load balancer audits: The following are some of the routing and exposure misconfigurations we encounter most often during AWS load balancer reviews. They are not the only possible ELB issues, but they are representative of a broader class of bugs where the configured routing graph does not match the intended security boundary. CloudFrontis often placed in front of an ALB to enforce WAF rules, geo-restrictions, caching policies, or rate limiting. In this setup, the ALB is expected to behave like a private origin: users should reach it only through CloudFront, not directly. The problem appears when the origin ALB is still Internet-facing and its security group allows public inbound traffic. In that case, an attacker could send requests directly to the ALB DNS name, bypassing every control enforced at the CloudFront layer, including WAF rules attached to the distribution. ALB listener rules are evaluated in ascending-priority order. A rule with priority10is evaluated before one with priority20. If a broad rule (e.g.,path /*) sits at priority10and a more restrictive rule (e.g.,path /admin*withauthenticate-oidc) sits at priority20, all traffic to/adminmatches the broad rule first. The auth action never fires. This is purely an ordering bug with a direct authentication bypass impact.