Cloudflare's Access policy documentation states that Bypass does not enforce Access security controls and its requests are not logged by Access. That is a valid product behavior, sometimes necessary for a health check or an integration. It is also a reason for an enterprise buyer to inventory every Bypass exception and test what can reach the application through it. A configuration list alone will not show whether a second route to the origin avoids the intended protection.
Quick answer. Scope the assessment by protected application and route. Review each Access policy's action, rule type, selector and value, then validate representative Allow, deny, Bypass and machine-access scenarios with test identities. Check whether the origin is reachable through an alternate hostname, direct route or excluded path that the customer owns. Collect authentication and request-log evidence for enforced paths; explicitly mark where Bypass produces no Access request log.
This guide is about customer-controlled Access configuration and application routing. It does not allege a Cloudflare platform vulnerability. All active tests should target the customer's authorized applications and designated identities, with any direct-origin probe agreed in the rules of engagement.
Figure 1: Four independent route outcomes are compared side by side; column order is not policy evaluation order. Sources: Cloudflare Access policies and Access log documentation.
The policy and the route both matter
Cloudflare describes an Access policy through four building blocks: action, rule type, selector and value. A protected application may have several policies, and a customer's origin may have several hostnames or network routes. Cloudflare evaluates Bypass and Service Auth policies first, in their configured order, then Block and Allow policies in their configured order. The assessment should therefore map a request's complete path: hostname, Access application, matched policy, identity or service credential, origin route and resulting application authorization.
An Access login success is not proof the application is secure. It shows that the edge policy admitted the request. The app still needs its own session and authorization controls. Conversely, a strong application login does not justify leaving an administrative origin path outside the intended Access policy. If the buyer wants both layers tested, scope the Access configuration and a separate web application penetration test with the same application owner.
The source of many findings is not a dramatic exploit. It is an exception whose purpose is forgotten, an overly broad selector or an alternate path that never crosses the policy. The assessor must confirm that the path is actually reachable by a designated lower-privilege test identity. A hostname in a spreadsheet, a firewall rule or a historic DNS record alone is insufficient evidence of an active bypass.
Four decisions to validate
Bypass exceptions
For each Bypass policy, record the business reason, matching condition, protected application, change owner and expected callers. Cloudflare states Bypass does not enforce Access controls and that those requests are not logged by Access. The assessment should test an approved matching and nonmatching case to show the actual boundary. Avoid sending traffic from unapproved networks or trying to enumerate external customer paths.
An exception that allows a narrowly identified health service may be appropriate. A Bypass condition that matches more traffic than its owner expects has a different risk. The report should show the selector and observed route, then propose a narrower condition or an alternative pattern. Do not call all Bypass usage a vulnerability; the product intentionally provides the action.
Where machine traffic needs access without a human identity-provider login, Cloudflare suggests Service Auth as an option that maintains enforcement and logging. The assessor should compare the customer's use case with that option and test a designated service credential if configured. Service Auth is not a universal replacement for every Bypass exception; the application protocol and health-check behavior may constrain the choice. State those constraints.
Broad Allow rules
Cloudflare warns that an Allow policy with a broad Include Everyone rule can let anyone matching it access an application. Review each broad selector in the context of the complete policy. Identify whether other requirements, such as an identity provider or device condition, actually restrict the tested route. Then use an authorized test account outside the intended population and record the decision.
The finding should say who gained access to which Access application and whether the underlying app still required its own authentication. Those are different impacts. Do not equate reaching an Access-protected login page with reading protected business data unless the test demonstrates that further authorization failed.
Origin and alternate routes
Map the hostnames, DNS records, tunnels, load balancers and origin listener paths associated with each protected application. Determine whether an approved test client can reach the origin directly or through another hostname without passing through Access. A configuration review can identify candidates; a controlled connection test establishes actual reachability. The rules of engagement should forbid disruptive scanning and name the specific origin endpoints permitted.
If the origin is reachable, ask whether it enforces its own authentication and whether network controls limit the alternate route. Report the layered outcome. A direct path with strong application auth is different from a direct path into an unauthenticated admin interface. Do not overstate a bypass based only on DNS or a server banner.
Authentication and request evidence
Cloudflare distinguishes authentication audit logs, which record login attempts, from per-request audit logs for individual HTTP requests by authenticated users. An assessor should collect the right evidence for each claim. A successful login event does not show every application request. A Bypass request lacks the Access request log that would otherwise help investigation, although other network or application logs may still exist.
For a designated test flow, correlate identity, matched policy, request outcome and the relevant log type. Cloudflare says non-identity authentication events, including service-token events, require its GraphQL Analytics API and do not appear in the Cloudflare One dashboard. Detailed per-request logs in the dashboard and Logpush are available to Enterprise customers. Confirm the customer's plan and log access before promising this correlation. Check who receives alerts for unusual service access or repeated denials. If no per-request log is available for the tested route, document that visibility gap and any compensating origin logging. Do not promise that enabling one log type captures traffic the product explicitly excludes.
An assessment matrix for security buyers
Scenario | Controlled validation | Evidence to receive |
|---|---|---|
Intended employee access | Use a test employee identity on the expected hostname. | Matched policy, authentication event and app response. |
Unapproved user | Use an authorized account outside the intended group. | Denial or unexpected Allow with selector context. |
Bypass exception | Compare a matching and nonmatching designated request. | Exception owner, policy condition, route and Access logging limit. |
Service Auth | Test a designated machine credential and an invalid case. | Enforcement decision and request evidence. |
Alternate origin route | Test only named customer-owned paths. | Reachability, origin authentication result and remediation owner. |
This is a proposed test design. It is not a claim that these conditions are present in a specific Cloudflare account. The report should label which hostnames, policies and origins were tested and which were reviewed only.
A worked exception review
Consider a hypothetical internal dashboard whose health-check endpoint is called by a monitoring service. The team added a Bypass policy because the monitor does not complete an interactive identity-provider login. A useful assessment starts with the monitor's documented source, hostname and path, then checks what the Bypass rule actually matches. It sends an approved test request that should match and another that should not. It records the Access and application responses, plus the logs available at the origin.
If the rule admits the intended health check but also a broader path, the finding should show the exact selector and resulting route. It should not infer that business data was exposed unless the test reaches a protected response. A health-check endpoint returning only a status may carry lower impact than an administrative page admitted through the same exception. The report should separate edge admission, origin reach and application authorization.
Cloudflare's Service Auth guidance gives the buyer a possible alternative when a machine needs enforced and logged access without a human login. The provider should test a designated service credential against the monitor's protocol and verify that normal health checks still run. If Service Auth is unsuitable for that workflow, the exception can still be narrowed and paired with origin controls or independent logging. The recommendation should reflect the measured behavior, not a blanket ban on Bypass.
The evidence problem with Bypass
Cloudflare says Bypass traffic is not logged by Access. A response team therefore cannot rely on Access request logs to reconstruct what passed through that exception. The assessment should identify alternative evidence: an origin access log, application event, network flow or monitoring event, depending on what the customer actually collects. If no suitable record exists, say so. Do not list an Access authentication log for a request that never authenticated through Access.
This distinction also matters in a retest. Closing a broad exception may produce new Access request events, while the earlier Bypass path has no equivalent baseline in Access logs. The retest should prove the previously admitted test request is now denied or correctly authenticated, and check the new logging path. A configuration diff alone does not establish that the effective route changed.
Map route ownership before assigning a fix
Cloudflare Access policy, DNS, origin network controls and application authorization may be managed by different teams. When a path remains reachable, the report should name the exact control that should have stopped it. A public origin address might be a network ownership issue; a broad Include Everyone rule is a policy issue; a login page that admits the test user but then exposes another user's records is an application issue. The provider should avoid a generic “Zero Trust bypass” finding that blurs all three.
For a portfolio of applications, group the work by routing pattern. Sample a directly exposed web app, a tunneled app, a machine-to-machine integration and an app with a documented exception if those patterns exist. Record which pattern each finding represents. The security team can then expand a confirmed route issue to similar applications without pretending the first sample covered every hostname.
The buyer should ask for an exception register with owner, purpose, matching selector, application, expected caller, alternate control, evidence source and review date. This is a compact operational artifact that persists after the penetration test. It can help teams retire exceptions when the underlying integration changes and avoid silently widening a policy during a future migration.
Safe scope and procurement criteria
The buyer should provide an application inventory, Access policy export or read-only administrative view, test identities, test service credentials where applicable, and approved origin endpoints. Name third-party applications and vendor-managed infrastructure that are excluded. Set rate limits, testing windows and a stop condition for availability or account lockout. The tester should not change a production policy to create a finding.
Ask the provider for a sample result showing policy match, request route, origin behavior and log correlation. Ask how it will distinguish a Bypass exception from an app authorization defect. Require remediation advice that names the correct owner: identity team for group membership, network team for origin reach, platform team for Access configuration, or application team for business authorization. Require a retest of the same path after the fix.
Stingrai is a global CREST-accredited penetration testing services company, incorporated in 2021 and based in Toronto, Canada. Its human-led cloud, network and web application testing can validate customer-owned Access routing, identity and origin controls when those surfaces are explicitly in scope. Two named penetration testers work on each human-led engagement, with findings posted as confirmed and retesting included. Stingrai offers one-time tests and continuous programs; its technical evidence can support an enterprise security review.
A controlled validation sequence
Map applications and routes. List Access applications, hostnames, origins, policy actions, exception owners and expected callers.
Select identities. Prepare approved employee, excluded and machine test cases. Name the origin endpoints and windows that may be probed.
Test outcomes. Record policy matches, allowed and denied results, Bypass behavior, origin reach and the relevant authentication or request logs.
Remediate and retest. Narrow a selector, replace an exception where suitable or close an alternate route through the customer's change process. Repeat the original cases.
The buyer should leave with a map of actual protected and unprotected routes, not a list of policy labels. That map can be updated as applications and business exceptions change.
Frequently Asked Questions
What does Cloudflare Access Bypass do?
Cloudflare says Bypass does not enforce Access security controls and those requests are not logged by Access. It can be a deliberate exception. An assessment should identify who owns the exception, what traffic matches it and what other controls or logs protect that route.
Is Service Auth a replacement for every Bypass policy?
No. Cloudflare suggests Service Auth when machine access needs enforcement and logging without a human identity-provider login. Whether it fits depends on the protocol and business workflow. Test the actual route and document exceptions that cannot use it.
Does an Allow policy with Include Everyone expose an application?
Cloudflare warns that a broad Include Everyone rule in an Allow policy can admit anyone matching the condition. An assessor should test the complete policy with an authorized identity outside the intended group, then distinguish Access admission from the application's own authentication and authorization.
How do Access authentication logs differ from per-request logs?
Cloudflare documents authentication logs for login attempts and per-request logs for individual HTTP requests made by authenticated users. A Bypass request is not logged by Access. A report should say which log type supports each conclusion and whether other origin logs are available.
What should a Cloudflare Access assessment report show?
It should map sampled applications, hostnames, policies, exceptions and origin routes. Each finding needs the test identity, matched condition, observed response, relevant log evidence, business owner and retest. It should state which routes were out of scope.
Related reading
References
Cloudflare. Access policies. Updated 1 October 2026; accessed 21 October 2026. Policy components, Bypass, Service Auth and broad Allow conditions.
Cloudflare. Access authentication logs. Updated 1 May 2026; accessed 21 October 2026. Authentication and per-request log distinctions.
Talk to Stingrai
To test customer-owned Access policies, exception paths and origin reach, get a quote or book a free discovery call. Include the applications, test identities and origin routes you can authorize.
