In ZAP's verification settings, what happens when a `loggedInRegex` misses, versus when a `loggedOutRegex` misses?

## The order matters more than the patterns A context's verification method holds two patterns, and it is natural to read them as symmetrical — one describes a logged-in page, one describes a logged-out page. They are not symmetrical. The check runs three tests in a fixed order, and the third is a fall-through: 1. Is a **logged-in** pattern configured and does it match? → verdict **authenticated**, counter `loggedin`. 2. Otherwise, is a **logged-out** pattern configured and does it **fail** to match? → verdict **authenticated**, counter `unknown`. 3. Otherwise → verdict **not authenticated**, counter `loggedout`. (There is a fourth case ahead of all three: if *neither* pattern is configured, the check returns authenticated immediately and records `noindicator`.) Test 2 is the surprise. Its logic is *I was told what logged-out looks like, I do not see it, therefore I have no evidence of a problem* — and *no evidence of a problem* is resolved as authenticated, not as an error. ## What each configuration actually does | configured | pattern present in the text | pattern absent | |---|---|---| | logged-in only | authenticated (`loggedin`) | **not authenticated** (`loggedout`) — re-login fires | | logged-out only | not authenticated (`loggedout`) | **authenticated** (`unknown`) | | both | logged-in wins if it matches | logged-out absent → authenticated (`unknown`) | Read the bottom row again. With both patterns configured, a response containing **neither** falls into test 2 and is treated as authenticated. With only the logged-in pattern configured, the same response falls through to test 3 and is treated as logged out. **Adding the second pattern changed a negative verdict into a positive one.** That is not a bug, but it is the opposite of what a reviewer assumes when they see two patterns where there was one, and it is why *more configuration* is not automatically *a stricter check* here. ## Why it is built this way The logged-out shape is the less reliable signal. An application shows its login form on a great many pages that are not in fact a logged-out session — an error page, a redirect target, a partial render. Treating every absence of the logged-out marker as a logout would produce constant spurious re-logins. Failing open on that test keeps a noisy signal from driving the expensive path. The cost is that the noisy signal cannot detect anything on its own. A logged-out pattern is a *veto*, not a *confirmation*. ## How to configure it - **Always configure a logged-in pattern.** It is the only one that produces a positive confirmation, and it is the only one whose failure mode is a re-login rather than a silent continuation. - Add a logged-out pattern **only** as a veto — to catch a specific interstitial such as a session-expired page that would otherwise still contain the logged-in marker. - Remember the match is a **search**, not a whole-string comparison, so a pattern hits anywhere in the header or body. A logged-in marker drawn from persistent site furniture — a navigation label that renders for anonymous visitors too, or a string that also appears in a bundled script — will match on a logged-out page and quietly confirm a session that no longer exists. - Prefer a marker that is **impossible to render anonymously**: an account identifier, a page only the authenticated route serves. ## The interaction with the strategy The asymmetry applies whatever strategy is selected, but the **text** the patterns run against changes, and that changes how often each test wins: - Under a **per-response** or **both** strategy, the patterns run against whatever the crawl fetched. Most of a crawl is not a page — it is assets, redirects and error bodies — and almost none of that contains either marker, so test 2 fires constantly and the `unknown` counter dominates. - Under a **polling** strategy, the patterns run against a response you deliberately chose, so a logged-in marker you picked for that page will match or genuinely fail. Test 2 fires far less often. - Under a **per-request** strategy, the patterns run against text the tool wrote itself, which rarely contains a server-rendered marker at all. That is a second reason to configure a positive indicator and to pick the poll strategy's endpoint deliberately: on the free strategies, *the weak test is the one that usually decides*. ## Checking the choice afterwards The verdicts are counted separately, which makes the configuration auditable. A run whose `unknown` count dominates is a run whose verification is resting entirely on test 2 — it has no positive confirmation of anything, and it will report authenticated whatever the target does short of rendering the exact logged-out marker. That is worth treating as a configuration defect even when the run looks clean.