Réponses:
Il est disponible dans l' en- referer
tête HTTP . Vous pouvez l'obtenir dans un servlet comme suit:
String referrer = request.getHeader("referer"); // Yes, with the legendary misspelling.
Cependant, vous devez vous rendre compte qu'il s'agit d'une valeur contrôlée par le client et qu'elle peut donc être usurpée en quelque chose d'entièrement différent ou même supprimée. Ainsi, quelle que soit la valeur renvoyée, vous ne devez pas l'utiliser pour des processus métier critiques dans le backend, mais uniquement pour le contrôle de la présentation (par exemple, masquer / afficher / modifier certaines parties de la mise en page pure) et / ou des statistiques.
Pour les intéressés, des informations sur la faute d'orthographe peuvent être trouvées sur Wikipedia .
null
.
En fait, c'est
:, request.getHeader("Referer")
ou même mieux, et pour être sûr à 100%
request.getHeader(HttpHeaders.REFERER)
, où se trouve HttpHeaderscom.google.common.net.HttpHeaders
getHeader(String name)
(citation):"The header name is case insensitive."
org.apache.http.HttpHeaders
Comme tous l'ont mentionné, c'est
request.getHeader("referer");
Je voudrais ajouter quelques détails supplémentaires sur l'aspect de sécurité de l'en- tête du référent par opposition à la réponse acceptée. Dans les feuilles de triche du projet Open Web Application Security ( OWASP ), sous la feuille de triche de prévention de la falsification des demandes intersites (CSRF), il mentionne l'importance de l'en- tête du référent .
Plus important encore, pour cette vérification recommandée de la même origine, un certain nombre d'en-têtes de requête HTTP ne peuvent pas être définis par JavaScript car ils figurent dans la liste des en-têtes «interdits». Seuls les navigateurs eux-mêmes peuvent définir des valeurs pour ces en-têtes, ce qui les rend plus fiables car même une vulnérabilité XSS ne peut être utilisée pour les modifier.
La vérification de l'origine de la source recommandée ici repose sur trois de ces en-têtes protégés: Origin, Referer et Host, ce qui en fait une défense CSRF assez solide à elle seule.
Vous pouvez consulter la liste des en-têtes interdits ici . L'agent utilisateur (c'est-à-dire le navigateur) a le contrôle total sur ces en-têtes et non sur l'utilisateur.