WEBVTT

00:00:01.840 --> 00:00:04.420
At the time the referer browser header was

00:00:04.420 --> 00:00:08.360
invented, it was misspelled; however, they

00:00:08.360 --> 00:00:10.680
never got the opportunity to correct it

00:00:10.690 --> 00:00:13.540
once it was widely used. The value of the

00:00:13.540 --> 00:00:16.080
header contains the origin the user came

00:00:16.079 --> 00:00:17.960
from. When you don't configure it

00:00:17.960 --> 00:00:20.190
otherwise, it is set automatically by the

00:00:20.190 --> 00:00:23.430
browser. If I post a tweet with a link to

00:00:23.430 --> 00:00:25.970
a blog post, the blog post site will

00:00:25.970 --> 00:00:28.349
receive a header with a URL to the tweet.

00:00:28.940 --> 00:00:30.935
The same happens when the redirect occurs,

00:00:30.935 --> 00:00:34.390
for example, when the A element in HTML is

00:00:34.390 --> 00:00:37.580
used. Services is like Google Analytics

00:00:37.590 --> 00:00:40.290
use the value off the referer header to

00:00:40.290 --> 00:00:43.160
show you where visitors to your site came

00:00:43.160 --> 00:00:46.860
from. You might think, hey, I don't want

00:00:46.870 --> 00:00:49.199
anybody to see where I came from, and

00:00:49.200 --> 00:00:52.340
you're right. These privacy issues may be

00:00:52.340 --> 00:00:55.620
even worse than you think. For example, an

00:00:55.620 --> 00:00:58.669
image hosted on a third‑party site, but

00:00:58.670 --> 00:01:01.239
embedded in your page could result in

00:01:01.240 --> 00:01:03.625
sensitive information being leaked to the

00:01:03.625 --> 00:01:06.850
third party. Even if security is not

00:01:06.860 --> 00:01:09.729
compromised, the information may not be

00:01:09.730 --> 00:01:12.414
something the user wants shared. And the

00:01:12.414 --> 00:01:14.860
referer header opens the door for exploits

00:01:14.860 --> 00:01:18.110
as well. For example, consider a reset

00:01:18.120 --> 00:01:20.720
password page with a social media link in

00:01:20.720 --> 00:01:23.390
the footer. If the link was followed,

00:01:23.400 --> 00:01:25.650
depending on how information was shared,

00:01:26.040 --> 00:01:28.870
the social media site may receive to reset

00:01:28.880 --> 00:01:31.700
password URL and may still be able to use

00:01:31.700 --> 00:01:33.950
the shared information, potentially

00:01:33.950 --> 00:01:38.280
compromising a user's security. Luckily,

00:01:38.280 --> 00:01:40.619
we can control the refer header by setting

00:01:40.620 --> 00:01:43.149
another header called Referrer‑Policy.

00:01:43.740 --> 00:01:46.649
Note that in this header, the word refer

00:01:46.650 --> 00:01:49.910
is spelled correctly in the ASP.NET Core

00:01:49.910 --> 00:01:52.240
demo solution, I've created another

00:01:52.240 --> 00:01:55.940
project called WiredBrain.Referrer. It

00:01:55.940 --> 00:01:58.380
just contains an index view for the home

00:01:58.380 --> 00:02:01.690
controller. The only thing in there is an

00:02:01.690 --> 00:02:05.410
a tag referring to the loyalty site. Now I

00:02:05.410 --> 00:02:08.460
run both apps. When I click the link,

00:02:08.669 --> 00:02:11.120
referer header is present in the response

00:02:11.120 --> 00:02:14.640
I get from the loyalty site. The loyalty

00:02:14.640 --> 00:02:18.250
site is running on both HTTPS and HTTP.

00:02:19.180 --> 00:02:21.810
Let's change the URL on the referer site

00:02:21.890 --> 00:02:25.440
to the HTTP address. When I now run and

00:02:25.440 --> 00:02:27.970
click the link, there is no refer header.

00:02:28.300 --> 00:02:30.900
That is because Chrome by default uses a

00:02:30.900 --> 00:02:32.340
refer policy of

00:02:32.340 --> 00:02:35.420
no‑referrer‑when‑downgrade. That means

00:02:35.630 --> 00:02:39.049
whenever a site running with HTTPS links

00:02:39.050 --> 00:02:42.470
to a non‑secure HTTP site, referer header

00:02:42.470 --> 00:02:44.720
is hidden. This rules out the

00:02:44.720 --> 00:02:46.649
man‑in‑the‑middle collecting refer

00:02:46.650 --> 00:02:49.670
information. In that way, we're sure only

00:02:49.670 --> 00:02:51.950
the site that is linked gets the header.

00:02:54.040 --> 00:02:55.660
Here are all options for the

00:02:55.660 --> 00:02:58.790
Referrer‑Policy header. No‑referrer just

00:02:58.800 --> 00:03:01.150
turns to referrer header off completely.

00:03:01.580 --> 00:03:04.030
Same‑origin means that referer header will

00:03:04.030 --> 00:03:06.760
only be present when a redirection occurs

00:03:06.760 --> 00:03:08.490
to the same domain and scheme.

00:03:09.440 --> 00:03:11.920
Strict‑origin is the same, except for the

00:03:11.920 --> 00:03:14.670
fact that referrals to non‑secure HTTP

00:03:14.670 --> 00:03:16.450
sites won't get the header.

00:03:17.950 --> 00:03:19.550
Origin‑when‑cross‑origin means that the

00:03:19.550 --> 00:03:22.780
full URL is sent to the same origin sites.

00:03:23.050 --> 00:03:25.575
All others will just get the base URL,

00:03:26.070 --> 00:03:28.880
nothing behind a slash. There's also a

00:03:28.880 --> 00:03:30.980
strict version of that. And finally,

00:03:31.160 --> 00:03:34.700
unsafe‑url always sends the full URL to

00:03:34.700 --> 00:03:37.830
all sites. The name kind of gives you a

00:03:37.830 --> 00:03:40.350
hint on whether you should use it or not.

00:03:41.340 --> 00:03:44.050
All these options are great, but which one

00:03:44.050 --> 00:03:47.170
to choose? I think the first question you

00:03:47.170 --> 00:03:49.710
should ask yourself is, is there a

00:03:49.710 --> 00:03:51.480
possibility that there is sensitive

00:03:51.490 --> 00:03:54.650
information in the URL? If that's the

00:03:54.650 --> 00:03:58.290
case, consider no‑referrer. If not, pick

00:03:58.550 --> 00:04:01.160
one that takes unsecure connections into

00:04:01.160 --> 00:04:06.079
account. Here's how to set the header. I'm

00:04:06.080 --> 00:04:08.390
using a web stack by setting the header

00:04:08.390 --> 00:04:10.720
using middleware filter, or web.config

00:04:10.720 --> 00:04:14.050
will also work. I set it to no‑referrer.

00:04:14.740 --> 00:04:18.529
I've also set the href of the a tag in the

00:04:18.529 --> 00:04:21.990
referer project back to the HTTPS address.

00:04:23.040 --> 00:04:25.490
When I run again and click the link on the

00:04:25.490 --> 00:04:27.750
receiving site, there's no trace of the

00:04:27.750 --> 00:04:30.610
refer header anymore. There's another way

00:04:30.610 --> 00:04:33.270
to control the header. In HTML elements,

00:04:33.270 --> 00:04:37.100
like img and a, you can just turn it off

00:04:37.110 --> 00:04:39.380
for that element only by specifying

00:04:39.380 --> 00:04:42.610
no‑referrer in the rel attributes. The

00:04:42.610 --> 00:04:44.960
advantage of this method is that you can

00:04:44.960 --> 00:04:47.700
be very specific about which links use

00:04:47.700 --> 00:04:51.490
referer and which don't. The policy is

00:04:51.490 --> 00:04:55.400
always globally applied. I've also added

00:04:55.400 --> 00:04:57.840
the referer policy header to the loyalty

00:04:57.840 --> 00:04:59.950
site itself and redeployed the

00:04:59.950 --> 00:05:03.190
application, and now we've got an A. We

00:05:03.190 --> 00:05:06.310
can make it an A+ if we also add a Strict

00:05:06.310 --> 00:05:09.290
Transport Security header, which make sure

00:05:09.330 --> 00:05:11.730
the browser connects to the site using

00:05:11.730 --> 00:05:14.979
HTTPS. I'm leaving the full explanation of

00:05:14.980 --> 00:05:16.930
this one to another course that covers

00:05:16.930 --> 00:05:20.090
this. It is in the same learning path or

00:05:20.090 --> 00:05:22.970
will be there soon. Let's take a look at

00:05:22.970 --> 00:05:25.110
how to control what version information

00:05:25.110 --> 00:05:28.150
ASP.NET emits in the next clip.
