CWE-287: Improper Authentication

This weakness occurs when authentication controls accept an identity claim without sufficiently proving it. It can result from missing authentication, incomplete validation, incorrect authentication logic, weak configuration, or an authentication mechanism that can be bypassed. The weakness concerns establishing identity and is distinct from authorization, which determines what an already identified actor is allowed to do.

The weakness may be introduced during architecture and design, or during implementation of a security design. It is not specific to a programming language, operating system, or technology, although the record identifies web-based systems and ICS/OT environments as applicable contexts. Typical manifestations include endpoints or services that accept unauthenticated requests, incorrectly validate credentials or tokens, omit an authentication factor, trust client-side checks, or implement authentication logic with faulty conditions.

An attacker may access data or functionality intended for another identity, disclose application data, gain privileges or assume another user's identity, and execute unauthorized code or commands. Depending on the affected system, the weakness can impact confidentiality, integrity, availability, and access control.

During architecture and design, use a dedicated authentication framework or library rather than implementing authentication controls ad hoc. The record specifically recommends an authentication feature such as the OWASP ESAPI Authentication feature.

Use multiple complementary approaches because automated analysis has limited coverage, especially for custom authentication and design or business-rule flaws. Static tools can inspect authentication-related configuration such as Apache .htaccess files and identify common authentication libraries, but they may miss custom schemes and may report false positives where functionality is intentionally public. Manual analysis, including penetration testing, threat modeling, interactive session testing, and review of custom authentication logic, is highly effective. Additional partial-coverage techniques include binary or bytecode disassembly with manual analysis, web application, web services, and database scanners, fuzzing and framework-based fuzzing, manual source-code review, source-code weakness analyzers, context-configured source-code weakness analyzers, and configuration checkers. Architecture and design review is highly cost effective when it uses IEEE 1028 inspections or formal methods and correct-by-construction techniques.

The official record provides the following representative examples, not an exhaustive list. They include unauthenticated file or API requests, missing or bypassed second-factor checks, acceptance of a None authentication type or empty credentials, client-side-only authentication, flawed comparisons and validation, default or hard-coded credentials, insecure cookies or parameters, protocol services without authentication, and predictable or replayable authentication values. Examples span file-sharing, chat, proxy, PLC, SCADA, DCS, cloud, router, Bluetooth, mail, LDAP, VoIP, and other products, including cases where authentication bypass enabled code execution, root-shell access, privileged access, or unauthorized command execution.