Short answer. Yes, blocking requests with an off-site Referer: header might have some security benefits, but I do not recommend that you implement it. The usability costs are significant and outweigh any security benefits.
I feel that, as security professionals, our job is not just to recommend defenses that people should implement -- it is also to identify defenses that people should not implement. This is one, in my personal opinion.
Background. Based on the original question, it sounds like it might be helpful to provide a review of the relevant background and articulate more precisely the specific defenses that you are likely considering.
You seem to be considering examining the
Referer: header in incoming requests. Most modern browsers set the
Referer: header on most requests to list the URL of the previous page that triggered this request or that contained this link. Some requests do not carry a
Referer: header; one example is the prior page is over HTTPS, then browsers will not set the
It is important to know that the
Referer: header was not designed for security, and cannot be trusted. There are many attacks to cause a browser to omit the
Referer: header. There are also attacks that can be used against some browsers to forge the
Referer: header (to cause the browser to send a request with a spoofed
Referer: header of the attacker's choice). Therefore, most security folks recommend that it is not a good idea to rely upon the
Referer: header as your main line of security.
It is also important to know that the
Referer: header is not guaranteed to be included, and sometimes it is blocked. The
Referer: header has privacy implications: it can be used to track people on the web. Some people feel that it is a violation of their privacy for their browser to routinely tell site B that they were just at some specific page on site A. Therefore, some people configure their browsers to block transmission of the
Referer: header. Also, some corporate firewalls and proxies strip out the
Referer: header, to avoid leaking confidential or proprietary information to external web sites.
The original RFC (RFC 2068) states that the
Referer: header is not mandatory, and explicitly recommends that browsers should provide a way for users to disable transmission of
For all of those reasons, some fraction of legitimate requests just don't include a
Now, I suspect you are proposing one of two possible defenses:
Strict Referer checking. You designate a specified landing page on your site. If your site receives a request with a
Referer: header that refers to any URL not on your site, or receives a request with no
Referer: header, then the server immediately responds with a redirect to your landing page.
Loose Referer checking. Same as the above, except that requests with no
Referer: header are permitted (they don't trigger the redirect).
Loose Referer checking makes no sense, from a security perspective: there are too many ways that an attacker can trigger a victim's browser to make a request and suppress the
Referer:. So I will presume that you are considering whether to implement strict Referer checking.
Security benefits. So, does strict Referer checking have potential security benefits? Yes. They include:
CSRF defense. Strict referer checking makes it harder to mount cross-site request forgery attacks, because other sites cannot direct the user anywhere other than the landing page.
XSS defense. Strict referer checking can make reflective XSS attacks harder, because other sites can't trick the victim's browser into visiting the vulnerable URL.
Clickjacking and framing. I don't know whether strict referer checking helps against clickjacking or being framed. I'll have to leave that to others.
There are some caveats, though. For each of these risks, there are better defenses known. For instance, for CSRF defense, use anti-CSRF tokens. For XSS defense, don't introduce XSS bugs into your software; use template systems with context-sensitive automatic escaping; etc. For clickjacking and framing, use time-tested frame-busting techniques.
Usability costs. There are some major usability costs to enabling strict referer checking throughout your site. These include:
It prevents deep linking. It prevents people from linking to pages on your web site. This means you won't get traffic that others send you, because they link to something great on your site.
It prevents deep bookmarking. It prevents your users from bookmarking anything other than the landing page. That's just annoying, from a user's standpoint.
It blocks some users. Some users won't be able to use your site, either because they use privacy mechanisms that block
Referer: headers, or because they're behind a corporate firewall that strips
Referer: headers, or the like. This reduces your potential user base. Also, some of the folks who block
Referer: headers are the most tech-savvy users, who are potentially your early adopters who might evangelize your site to others; you don't want to unnecessarily block them from using your site.
Overall. So, when I look at this, I see some dubious security benefits, and major usability costs. Moreover, all of those security benefits can be obtained in other ways that don't damage usability, simply by using standard security mechanisms. Therefore, I don't recommend that you adopt strict referer checking.