Since this is a computer security attack, I would think that it would be ethical to address a solution to this attack.
- Perhaps not, but there are still some things that can be done. For example, I disallow GET and HEAD requests where the request and referrer fields are the same - which logically should never happen as pages that refer to themselves do not cause browsers to (re-)fetch them upon clicking on such links. However, certain malicious spiders do present such bogus requests. I also check for off-server hotlinking. 188.8.131.52 (talk) 02:55, 5 October 2011 (UTC)
Someone needs to check those links.
- I'm uneasy about this; Wikipedia shouldn't be seen as abetting fraud. Rhinoracer 15:03, 28 September 2007 (UTC)
Cross-site request forgery
Currently this page is concerned with clients who intentionally spoof their own referrer. It should also discuss how and when an attacker performing cross-site request forgery can cause the victim to misrepresent their referrer (in order to circumvent referrer-based CSRF countermeasures), and how users can ensure that this isn't possible. —Saric (Talk) 16:04, 13 January 2012 (UTC)
- Now there's a sentence about unintentional spoofing as well, but now it sounds like a third party can set the Referer header to arbitrary values. This is simply not true. But in some cases the Referer header is missing, e.g. if the source "web page" is a local file or a link in a local application, e.g. an e-mail client. (However, there used to be a bug in old versions of Flash that allowed any HTTP header to be set to any value, but the very same version also allowed remote code execution, which would have allowed CSRF tokens, session ids, or even (soft) client certificates to be read). --Crashie (talk) 12:27, 20 October 2016 (UTC)