Skip to main content

Command Palette

Search for a command to run...

Broken Access Control Using the Referer Header

Updated
2 min read
Broken Access Control Using the Referer Header

NOTE: This post is for educational purposes only. Please use the information responsibly and legally.

While analyzing a request to /index.php, I noticed that it included a Referer header,This made me curious why a simple GET request depended on a Referer value.

GET /index.php HTTP/1.1 Host: demo-app.example.comUser-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Authorization: Basic ZGVtbzpwYXNzd29yZDEyMw== Connection: close Referer: https://demo-app.example.com/dashboardCookie: session_id=abc123xyz; loggedin=0 Upgrade-Insecure-Requests: 1 Priority: u=0, i

Step 1: Removing the Referer Header

I removed the Referer header entirely and sent the request again.
The server responded with an error, indicating that the Referer header was required to receive a 200 OK response.

This suggested that the application relied on the Referer header for access control.

GET /index.php HTTP/1.1 Host: demo-app.example.comUser-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Authorization: Basic ZGVtbzpwYXNzd29yZDEyMw== Connection: close Referer: https://liioon_the_great.com/dashboard Cookie: session_id=abc123xyz; loggedin=0 Upgrade-Insecure-Requests: 1 Priority: u=0, i

Step 2: Testing with a Fake Referer

Next, I added the Referer header back but replaced it with a fake domain:

Copy

Referer: https://liioon_the_great.com/dashboard

Surprisingly, the server still returned 200 OK, even though the Referer value was completely untrusted

Vulnerability Identified

This confirms a Broken Access Control vulnerability, where the application trusts a client-controlled Referer header to authorize access. Since attackers can freely modify this header, they can bypass access restrictions.

Summary:
When the Referer header was removed, the server returned an error response of 67 bytes.
When any Referer value was supplied — including a fake domain — the response length increased to 567 bytes, identical to the authorized response.
This confirms that the application relies solely on the presence of the Referer header for access control, rather than validating its value.

More from this blog

VulnVault

8 posts