Join our Newsletter — 33% off our NHI Course

CWE-288

CWE-288 is a weakness class for authentication bypass by alternate path or channel. It occurs when a system exposes a different route to a protected function, such as a secondary endpoint, proxy, direct object reference, or non-primary interface, that skips the intended access check and lets an unauthorised actor reach the resource.

What an alternate path or channel weakness means

CWE-288 describes a design or implementation flaw where a protected action can be reached through a route other than the intended primary path, and that alternate route does not enforce the same authentication check.

The key idea is not that the system lacks authentication entirely, but that the control is applied inconsistently across interfaces, handlers, or lookup paths. That makes the weakness especially dangerous in applications with multiple entry points, legacy interfaces, proxies, direct object references, or admin-only functions exposed through more than one channel.

Why alternate-path bypasses are dangerous

When a system protects one interface but leaves another route less protected, attackers look for the weaker path instead of breaking the stronger one. That can turn a seemingly well-guarded function into an exposed privilege boundary.

Bypasses of this kind often arise from inconsistent request handling, duplicated authorization logic, or assumptions that a “hidden” endpoint will not be reached directly. Those assumptions fail quickly once an attacker maps the application surface and tests non-primary routes, alternate verbs, alternate hostnames, or direct object references.

For a broader weakness taxonomy and related root causes, the CWE Top 25 Guide helps place this pattern alongside other high-impact software weaknesses.

Where organisations should look for exposure

Exposure review starts with finding every way a protected function can be invoked, not just the main UI path. That includes APIs, admin panels, mobile endpoints, reverse proxies, alternate domains, direct object references, and internal-only interfaces that may still be reachable from a compromised network position.

Teams should compare intended access rules across all of those paths and look for mismatches in authentication, session validation, object-level checks, or role enforcement. A weakness may exist even if the main user journey appears correct, because the bypass often lives in a side channel or fallback handler.

That is why terms in the CWE family are often best reviewed alongside lifecycle and relationship mapping guidance such as the CVE, CWE and CPE Guide, which shows how weakness classes map to exploitable product conditions.

Remediation and verification after the fix

Remediation usually means removing the alternate route, centralising the access check, or ensuring every route calls the same authorization logic before any sensitive object or action is returned. The objective is consistency: every path to the protected function should fail closed unless the caller is properly authenticated and allowed.

After a fix, verification should not stop at the originally reported endpoint. Test adjacent routes, proxy paths, alternate content types, legacy handlers, direct object references, and any internal or undocumented interface that could still expose the same function. Security testing should confirm that the bypass is gone everywhere, not only where it was first observed.

Because this weakness is a control-flow problem, secure design and implementation standards are often useful companions. For web-facing functions, the OWASP API Security Top 10 is a useful reference for broken authorisation patterns that often show up as alternate-path access flaws. For broader control design, NIST SP 800-53 Rev 5 Security and Privacy Controls provides access control and audit expectations that help catch inconsistent enforcement.

Detection and post-compromise review

Detection should focus on unexpected access paths, not only obvious login failures. Repeated requests to obscure endpoints, direct object identifiers, unusual proxy traversal, or successful access through non-primary interfaces can indicate that an attacker is probing for a bypass.

If exploitation is suspected, review access logs, authorization events, and object access patterns across every interface that can reach the affected function. A successful bypass may expose data, alter records, or grant access without leaving the same signals as a normal authentication failure, so post-incident analysis needs to follow the route, not just the user identity.

For detection and adversary-path analysis, MITRE ATT&CK Enterprise Matrix is useful for thinking about how attackers chain credential access, privilege escalation, and lateral movement after an access-control flaw is found.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP ASVS V8 — Authorization CWE-288 is an authorisation bypass through an alternate path.
Recommendation — Verify every route enforces the same authorisation checks before sensitive actions execute.
OWASP API Security Top 10 API5 — Broken Function Level Authorization Alternate-path bypasses often expose protected functions through a weaker route.
Recommendation — Harden function-level checks on all API routes and fail closed on secondary paths.
NIST SP 800-53 Rev 5 AC-3 — Access Enforcement This weakness is fundamentally inconsistent access enforcement across paths.
AU-2 — Audit Events Detecting bypass attempts depends on logging the relevant access paths and decisions.
Recommendation — Enforce access decisions centrally so alternate channels cannot bypass policy. Log access attempts across primary and alternate paths to support bypass detection.
NIST CSF 2.0 PR.AA-01 — Identity Management, Authentication, and Access Control CWE-288 weakens access control by allowing a non-primary route to reach protected functions.
Recommendation — Apply consistent identity and access control rules across every exposed interface.