Bypass

A bypass does not break the control, it goes around it, and that distinction changes where you look for it. If an attacker cracks a password, authentication did its job and lost. If they find a route that never reaches the login form, the control is intact and never hears about the visit at all.

That is why a bypass almost always grows out of an assumption rather than a product vulnerability. The control assumes every request comes through the front door, that the browser honours what the server told it, that the identifier in the URL belongs to the user who signed in. Each assumption holds nearly all of the time, and a bypass is the case where it does not.

The practical consequence is that scanners rarely find one. A scanner checks that the control exists and answers; the bypass lives on the path the scanner never walks.

Authentication bypass. An API endpoint nobody protected because it never appears in the menu, a password reset flow that hands back a session without asking for the second factor, a session cookie the server accepts without checking its signature. Multi-factor authentication is where this shows up most: it goes on the normal login and gets forgotten on reset, on federated sign-in, or in the mobile app.

Filtering bypass. A WAF and a firewall decide from what they can see, and what they see depends on how they parse the traffic. Encoding the payload differently, splitting it into fragments that reassemble later, or carrying it inside an allowed protocol are the classic ways to keep the rule from firing. The filter is not broken. It is looking somewhere else.

Access control bypass. Changing an identifier in the URL, calling an administrative function directly that the interface only shows to administrators, or requesting the same resource by an alternative path. This is the territory of IDOR and broken authorisation, and it is the most common bypass in web applications because the check gets written once per screen instead of once per record.

A successful bypass produces legitimate traffic. The request that skipped the control arrives well formed, with a valid session and a 200 response, so in the log it looks like any other user. What gives a bypass away is not an error, it is a sequence: a user reaching a resource they never asked for, a session created with no record of the second factor, a run of identifiers requested in order.

So the detection that works looks at relationships rather than isolated events. Logging the authorisation decision, and not only the access, is what makes a bypass visible: if the system records who asked for what and under which permission it was granted, the jump leaves a trace. If it only records that a 200 went out, it does not.

The prevention that matters comes earlier than any of that. Keeping software patched removes the bypasses that are already published; what remains belongs to your own design, and those only surface if somebody tests for them.

In a web application penetration test a bypass is not a category we go looking for on its own. It is found by repeating every privileged operation from an account that should not be able to perform it, and then from no account at all. That second pass is what finds the route the interface never shows.

The questions are always the same ones. Is the permission checked on the server, or is the button merely hidden? Is the second factor required on every entry path, or only on the main one? What happens when the request arrives without the header the filter expects? What happens when it arrives twice at once?

The finding is written against the place where the check is missing, not against the request that demonstrated it. A bypass fixed by blocking the exact payload that proved it comes back the following week in a different encoding.