At work we use a central portal that provides basic SSO functionality to other applications. In addition to verifying the SSO data sent, all of our existing in-house applications (used by the public) also check the referrer header to make sure that the user is actually coming from our central portal. However, we just experienced an issue where a JavaScript code change in the central portal caused Internet Explorer to stop forwarding the referrer header, which brought down all the apps that check that header.

My question is whether checking the referrer header provides any real world security improvement over just checking the basic SSO information (encrypted user ID contained in a cookie)? If it doesn't, is there any documentation/research/etc. that I could use to prove this to management?

I should also mention that unfortunately the central portal is a third party app which we don't have much control over ... so basic SSO information in the form of an encrypted cookie and referrer header information is all we have to help secure things.

1 Answer 1


From the OWASP

The referrer field (actually spelled 'referer') in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.

The OWASP actually regards this as vulnerability when used as the sole integrity or authentication method.

Increasingly, I've observed bots no longer use blank referrers but use the target's domain name or use www.google.com.

If you are dealing an advanced persistent threat, the the attackers could easily identify referer based challenges and bypass them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.