== Why is this an issue?

The fields in an HTTP request are putty in the hands of an attacker, and you cannot rely on them to tell you the truth about anything. While it may be safe to store such values after they have been neutralized, decisions should never be made based on their contents.


This rule flags uses of the referer header field.


=== Noncompliant code example

[source,java]
----
public class MyServlet extends HttpServlet {
  protected void doPost(HttpServletRequest request, HttpServletResponse response) 
        throws ServletException, IOException {
    String referer = request.getHeader("referer");  // Noncompliant
    if(isTrustedReferer(referer)){
      //..
    }
    //...
  }
}
----

== Resources

* OWASP - https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication[Top 10 2017 Category A2 - Broken Authentication]
* CWE - https://cwe.mitre.org/data/definitions/807[CWE-807 - Reliance on Untrusted Inputs in a Security Decision]
* CWE - https://cwe.mitre.org/data/definitions/293[CWE-293 - Using Referer Field for Authentication]


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

"referer" header should not be relied on


'''
== Comments And Links
(visible only on this page)

=== on 2 Oct 2014, 19:32:47 Nicolas Peru wrote:
This is slightly different than what we discussed, in my mind, this rule should detect calls to request.getHeader("referer"). So a compliant solution should not have this call at all.

=== on 3 Oct 2014, 14:07:20 Ann Campbell wrote:
\[~nicolas.peru] I'm assuming it's the code samples, rather than the description that you take issue with. Better now?

=== on 8 Oct 2014, 07:28:53 Nicolas Peru wrote:
Ok ! :) 

=== on 12 Dec 2014, 20:51:57 Sébastien Gioria wrote:
\[~nicolas.peru]: I disagree. You could have calls to request.getHeader("referer"); but you should never use the value returned to perform an authentication or autorization.



=== on 12 Dec 2014, 20:56:02 Nicolas Peru wrote:
\[~sebastien.gioria]I agree but how would you distiguish risky calls from correct one ? Idea here is to raise all calls to this method to let the security auditor mute the acceptable ones.

=== on 12 Dec 2014, 21:07:38 Sébastien Gioria wrote:
It the job of the security auditor ;) to distinguish it. If the idea is to trigger attention of the Security auditor, this could be OK. 

=== on 17 Feb 2021, 09:03:11 Eric Therond wrote:
This rule is not in SonarWay

we can safely deprecate it because taint analysis rules do a better job (referer header is a source) than this rule.

endif::env-github,rspecator-view[]
