CWEweakness
CWE-293 Using Referer Field for Authentication
High
Official page ↗
- Alternate terms
- referrer
- Abstraction
- Variant
- Structure
- Simple
- Status
- Draft
- Likelihood of exploit
- High
- Languages
- Not Language-Specific
- CWE version
- 5.0
Description
The referer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.
Common consequences
• Access Control: Gain Privileges or Assume Identity — Actions, which may not be authorized otherwise, can be carried out as if they were validated by the server referred to.
Potential mitigations
• [Architecture and Design] In order to usefully check if a given action is authorized, some means of strong authentication and method protection must be used. Use other means of authorization that cannot be simply spoofed. Possibilities include a username/password or certificate.
Detection methods
• Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Related
Child of · CWE (1)
- CWE-290 Authentication Bypass by Spoofing weakness
Referenced by CVE · weakness (1)
- CVE-2023-20025 A vulnerability in the web-based management interface of Cisco Small Business RV016, RV042, RV042G, and RV082 Routers could allow an… vulnerability
Referenced by OWASP · mapped cwe (1)
- A07:2025 Authentication Failures Top 10 2025