Why using referer header as a security mechanism is a bad idea

Some organisations use the HTTP referer header as a way to authorize access to resources that they host, this was most commonly used for preventing deeplinking to artwork but now also seems to make it’s way into webmapping resources such as tilecaches.
Here are some good reasons why not.

It breaks accessibility

The HTTP specifications have the referer header as an optional element, HTTP clients (eg. browsers, screen readers,… ) are not required to implement this feature or may choose to send it empty. When authorisation is based on the referer header the user will be refused access. Most modern browsers have a “enhanced privacy mode” that will remove the referrer header next to refusing all sorts of other tracking mechanisms, which the header was initially designed for.

Lack of authentication

Using referer checking is authorisation without authentication, plainly, just a bad idea.

Easy to forge

It is easily forged, well forged… since it is not required information a user can pretty much do what they want with this information field. There are various browser extensions and proxy servers that let you modify the referer header thus rendering it useless or granting user access to resources they shouldn’t be getting.


Huh? OWASP?? The Open Web Application Security Project keeps a list of commonly made mistakes and vulnerabilities that have been spotted in the wild. They are an authoritative source of “the wrong thing to do”. Referer header checking is way up on their list of “don’t do this or else”.

Join 59 other followers
GISpunt logo


%d bloggers like this: