Cloudflare Access: Bypass policy exposure for health check endpoints
0 reputation · 20 Sept 2021, 08:09 UTC
0 reputation · 20 Sept 2021, 08:09 UTC
Cloudflare Access is designed to protect origin servers by enforcing identity-based policies. A common requirement is allowing external monitoring services or load balancer health checks to reach specific endpoints without triggering an authentication challenge.
To achieve this, a Bypass policy is typically implemented for specific paths or IP ranges. However, there is a design uncertainty regarding how these rules interact with broader application policies when overlapping paths are defined. If a health check path is a subset of a protected directory, the priority of the bypass rule could inadvertently expose other sensitive assets if the path matching is too permissive.
/health or /status endpoints.Does the Cloudflare Access policy engine prioritize a specific Bypass rule over a global Allow rule when both match the request URI? How can a configuration be verified to ensure the bypass is limited strictly to the health check endpoint without opening a hole for the rest of the application?
33775 reputation · 20 Sept 2021, 09:57 UTC
Cloudflare Access evaluates policies sequentially from top to bottom. If a Bypass rule and an Allow rule both match the same request URI, the rule that is listed first determines the outcome. Therefore, placing a Bypass rule for the health‑check path above any broader Allow rule guarantees unauthenticated access to /health (or /status) while keeping the default‑deny posture for the rest of the application.
Path → /health (exact match) or /status as needed.203.0.113.0/24). This prevents the bypass from being triggered by arbitrary internet traffic./*).curl -I https://example.com/healthshould show
Action: Bypass and no Cf-Access-Authenticated-User header.
Testing a protected path (e.g., https://example.com/api/data) from the same source should return Action: Allow (or Block) with an authentication challenge.action is bypassed for /health requests and challenged or allowed after authentication for other paths.curl -I https://example.com/healthExpect HTTP 200 without a
Cf-Access-Authenticated-User header.curl -I https://example.com/privateExpect either 401/redirect to login or a 200 only after presenting valid credentials.
The behavior described relies on the documented sequential evaluation of Access policies. If Cloudflare changes the evaluation order in a future release, the precedence could shift. Therefore, after any platform update, re‑run the verification steps to confirm that the Bypass rule still takes priority.
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 20 Sept 2021, 14:43 UTC
While sequential evaluation ensures the Bypass rule takes precedence, it is important to account for how Cloudflare Access handles path matching. By default, path rules can act as prefixes; for example, a bypass rule for /health might inadvertently match /health-admin or /health/config if not strictly defined.
To maintain a strict "Default Deny" posture, verify the following during implementation:
/health, avoid using trailing wildcards.Bypass rules strip identity context, the origin server should ideally verify the request source IP independently to provide a second layer of defense.