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

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

== See

* https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication[OWASP Top 10 2017 Category A2] - Broken Authentication
* http://cwe.mitre.org/data/definitions/807[MITRE, CWE-807] - Reliance on Untrusted Inputs in a Security Decision
* http://cwe.mitre.org/data/definitions/293[MITRE, CWE-293] - Using Referer Field for Authentication
* https://www.sans.org/top25-software-errors/#cat3[SANS Top 25] - Porous Defenses


ifdef::env-github,rspecator-view[]
== Comments And Links
(visible only on this page)

include::comments-and-links.adoc[]
endif::env-github,rspecator-view[]
