CWE-293: Using Referer Field for Authentication

Code Examples & CVEs

Demonstrative Examples

The following code samples check a packet's referer in order to decide whether or not an inbound request is from a trusted host.

These examples check if a request is from a trusted referer before responding to a request, but the code only verifies the referer name as stored in the request packet. An attacker can spoof the referer, thus impersonating a trusted client.

BadC++

String trustedReferer = "http://www.example.com/"while(true){n = read(newsock, buffer, BUFSIZE);requestPacket = processPacket(buffer, n);if (requestPacket.referer == trustedReferer){openNewSecureSession(requestPacket);}}

The following code samples check a packet's referer in order to decide whether or not an inbound request is from a trusted host.

BadJava

boolean processConnectionRequest(HttpServletRequest request){String referer = request.getHeader("referer")String trustedReferer = "http://www.example.com/"if(referer.equals(trustedReferer)){openPrivilegedConnection(request);return true;}else{sendPrivilegeError(request);return false;}}

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Verify controls for CWE-293 with SSDF evidence

Use NIST SSDF verification and vulnerability-response practices to detect CWE-293, Using Referer Field for Authentication, throughout the product lifecycle. Derive review questions, static or dynamic checks, and negative tests from the CWE's causal behavior; define the components and lifecycle stages each check covers; and retain findings with enough evidence to distinguish the root cause from symptoms and impacts. Track escapes and false negatives, then improve the verification plan after every confirmed occurrence.

NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and Technology

Address Using Referer Field for Authentication during Architecture and Design

MITRE associates mitigation with Architecture and Design; documented detection approaches include Automated Static Analysis; recorded impacts include Gain Privileges or Assume Identity. Use these source-defined anchors to turn CWE-293 into implementation, review, and verification checks for the affected component.

CWE-293: Using Referer Field for Authentication — MITRE CWE

Triage CWE-293 against known exploitation evidence

Use CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-293, Using Referer Field for Authentication, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.

Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency

Apply precise root-cause mapping to CWE-293

Apply MITRE's full root-cause mapping guidance when using CWE-293, Using Referer Field for Authentication. Separate weakness language from attacker prerequisites and technical impact, check the entry's abstraction and vulnerability-mapping notes, and prefer the most specific Base or Variant supported by the evidence. Record the rejected alternatives and require an independent review before the mapping is used for remediation trends or program metrics.

CVE to CWE Root Cause Mapping Guidance — MITRE CWE

Validate CWE-293 with root-cause mapping checks

Apply MITRE's root-cause mapping quick tips to CWE-293, Using Referer Field for Authentication. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.

CVE to CWE Root Cause Mapping Quick Tips — MITRE CWE

Frequently Asked Questions

What is CWE-293: Using Referer Field for Authentication?+

CWE-293: Using Referer Field for Authentication is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The referer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.

What are the security consequences of Using Referer Field for Authentication?+

If exploited, CWE-293 (Using Referer Field for Authentication) it can compromise Access Control, leading to outcomes such as Gain Privileges or Assume Identity.

How do you prevent or mitigate Using Referer Field for Authentication?+

Recommended mitigations for CWE-293 include: 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.

Which programming languages are affected by Using Referer Field for Authentication?+

CWE-293 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-293 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.

CWE-293: Using Referer Field for Authentication

Technical Details

Applicable To

Security Consequences

Scope

Impact

Mitigation Strategies

Phase

Description

Detection Methods