A new security header: Referrer Policy
Security researcher, entrepreneur and international speaker who specialises in web technologies.
Scott Helme
Regular readers will know how fond I am of the existing security headers so it’s great to hear that we’re getting another! Referrer Policy will allow a site to control the value of the referer header in links away from their pages.
What’s a referrer?
When a user clicks a link on one site, the origin, that takes them to another site, the destination, the destination site receives information about the origin the user came from. This is how we get metrics like those provided by Google Analytics on where our traffic came from. I know that 4,000 users came from Twitter this week because when they visit my site they set the referer[sic] header in their request.
This referer header lets me know where the inbound visitor came from, and is really handy, but there are cases where we may want to control or restrict the amount of information present in this header like the path or even whether the header is sent at all.
The Referrer Policy header
The spec for Referrer Policy has been a W3C Candidate Recommendation since 26 January 2017 and can be found here but I’m going to cover everything in this blog to save you the trouble. The Referrer Policy is issued via a HTTP response header with the same name, Referrer-Policy , and can contain one of the following values as defined in the spec:
I will break down each value and explain what the effects of issuing it would be.
Empty String
An empty string value in the Referrer Policy header indicates that the site doesn’t want to set a Referrer Policy here and the browser should fallback to a Referrer Policy defined via other mechanisms elsewhere. This can include a HTML <meta> element, a referrerpolicy attribute on elements like <a> and <link> or the rel="noreferrer" keyword on <a> tags too. Issuing this policy will effectively have no impact but just confirms that the site has intentionally omitted it. You can even set your Referrer Policy via the Content Security Policy header if you like.
no-referrer
The no-referrer value instructs the browser to never send the referer header with requests that are made from your site. This also include links to pages on your own site.
| Source | Destination | Referrer |
|---|---|---|
| https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | NULL |
| https://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | NULL |
| http://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | NULL |
| http://scotthelme.co.uk/blog1/ | http://example.com | NULL |
| http://scotthelme.co.uk/blog1/ | https://example.com | NULL |
| https://scotthelme.co.uk/blog1/ | http://example.com | NULL |
no-referrer-when-downgrade
The browser will not send the referrer header when navigating from HTTPS to HTTP, but will always send the full URL in the referrer header when navigating from HTTP to any origin. It doesn’t matter whether the source and destination are the same site or not, only the scheme.
| Source | Destination | Referrer |
|---|---|---|
| https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | NULL |
| https://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/blog1/ |
| http://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | http://scotthelme.co.uk/blog1/ |
| http://scotthelme.co.uk/blog1/ | http://example.com | http://scotthelme.co.uk/blog1/ |
| http://scotthelme.co.uk/blog1/ | https://example.com | http://scotthelme.co.uk/blog1/ |
| https://scotthelme.co.uk/blog1/ | http://example.com | NULL |
same-origin
The browser will only set the referrer header on requests to the same origin. If the destination is another origin then no referrer information will be sent.
| Source | Destination | Referrer |
|---|---|---|
| https://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/blog1/ |
| https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | NULL |
| https://scotthelme.co.uk/blog1/ | http://example.com/ | NULL |
| https://scotthelme.co.uk/blog1/ | https://example.com/ | NULL |
origin
The browser will always set the referrer header to the origin from which the request was made. This will strip any path information from the referrer information.
| Source | Destination | Referrer |
|---|---|---|
| https://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/ |
| https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/ |
| https://scotthelme.co.uk/blog1/ | http://example.com/ | https://scotthelme.co.uk/ |
Warning: Navigating from HTTPS to HTTP will disclose the secure origin in the HTTP request.
strict-origin
This value is similar to origin above but will not allow the secure origin to be sent on a HTTP request, only HTTPS.
| Source | Destination | Referrer |
|---|---|---|
| https://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/ |
| https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | NULL |
| https://scotthelme.co.uk/blog1/ | http://example.com/ | NULL |
| http://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | http://scotthelme.co.uk/ |
| http://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | http://scotthelme.co.uk/ |
| http://scotthelme.co.uk/blog1/ | http://example.com/ | http://scotthelme.co.uk/ |
origin-when-cross-origin
The browser will send the full URL to requests to the same origin but only send the origin when requests are cross-origin.
| Source | Destination | Referrer |
|---|---|---|
| https://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/blog1/ |
| https://scotthelme.co.uk/blog1/ | https://example.com/ | https://scotthelme.co.uk/ |
| https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/ |
| https://scotthelme.co.uk/blog1/ | http://example.com/ | https://scotthelme.co.uk/ |
| http://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | http://scotthelme.co.uk/ |
Warning: Navigating from HTTPS to HTTP will disclose the secure URL or origin in the HTTP request.
strict-origin-when-cross-origin
Similar to origin-when-cross-origin above but will not allow any information to be sent when a scheme downgrade happens (the user is navigating from HTTPS to HTTP).
| Source | Destination | Referrer |
|---|---|---|
| https://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/blog1/ |
| https://scotthelme.co.uk/blog1/ | https://example.com/ | https://scotthelme.co.uk/ |
| https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | NULL |
| https://scotthelme.co.uk/blog1/ | http://example.com/ | NULL |
unsafe-url
The browser will always send the full URL with any request to any origin.
| Source | Destination | Referrer |
|---|---|---|
| https://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/blog1/ |
| https://scotthelme.co.uk/blog1/ | https://example.com/ | https://scotthelme.co.uk/blog1/ |
| https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/blog1/ |
| https://scotthelme.co.uk/blog1/ | http://example.com/ | https://scotthelme.co.uk/blog1/ |
Warning: Navigating from HTTPS to HTTP will disclose the secure URL in the HTTP request.
Recommendations
Which header you will want or need to use will depend on your requirements but there are some that you should probably stay away from. The unsafe-url value kind of gives you a hint in the name and I wouldn’t really advise anyone use it. Likewise if you’re thinking of using origin or origin-when-cross-origin then I’d recommend looking at strict-origin and strict-origin-when-cross-origin instead. This will at least plug the little hole of leaking referrer data over an insecure connection. I don’t have anything sensitive in the URL for my site so I will probably look at a value like no-referrer-when-downgrade just to keep referrer data off HTTP connections.
securityheaders.io
I’ve added this header to securityheaders.io as it’s now a W3C Candidate Recommendation and it does count towards your score. You can see the new results for my site here:
Of course, you can’t achieve a grade A now without the new Referrer-Policy header properly configured. If you try and set it with no policy, or a bad policy, it’s not going to help you.
You have to set the header and use a good policy to be awarded top marks!
It will be interesting to see how much of an impact this has on the grading criteria as it will drag grades down across the board. Hopefully sites will be fast to respond in deploying the new header and asserting more control over the information shared with referrer data.
If you want to get notified when I publish a new blog, please consider subscribing!
Security HTTP Headers
Last few years a bunch of new HTTP headers were added to the web platform. The purpose of this blog post is to discuss the most critical headers from a security perspective.
X-Frame-Options
This http header helps avoiding clickjacking attacks. Browser support is as follow: IE 8+, Chrome 4.1+, Firefox 3.6.9+, Opera 10.5+, Safari 4+. Posible values are:
deny browser refuses to display requested document in a frame sameorigin browser refuses to display requested document in a frame, in case that origin does not match allow-from: DOMAIN browser displays requested document in a frame only if it loaded from DOMAIN
Figure 1. X-Frame-Options
Note: The Content-Security-Policy HTTP header has a frame-ancestors directive which obsoletes this header for supporting browsers.
X-XSS-Protection
Use this header to enable browser built-in XSS Filter. It prevent cross-site scripting attacks. X-XSS-Protection header is supported by IE 8+, Opera, Chrome, and Safari. Available directives:
0 disables the XSS Filter 1 enables the XSS Filter. If a cross-site scripting attack is detected, in order to stop the attack, the browser will sanitize the page. 1; mode=block enables the XSS Filter. Rather than sanitize the page, when a XSS attack is detected, the browser will prevent rendering of the page. 1; report=<reporting-URI> enables the XSS Filter. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation.
X-Content-Type-Options
This http header is supported by IE and Chrome, and prevents attacks based on MIME-type mismatch. The only possible value is nosniff . If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type. The list with available MIME-types for styles and scripts is as follow:
- text/css
- application/ecmascript
- application/javascript
- application/x-javascript
- text/ecmascript
- text/javascript
- text/jscript
- text/x-javascript
- text/vbs
- text/vbscript
So if you try to load for example a HTML document as external script resource (the src attribute of HTMLScriptElement), the browser will refuse it.
Figure 1. X-Content-Type-Options
Strict-Transport-Security
To take advantage of this security header, the current webpage must be accessed over HTTPS. In this case the Strict-Transport-Security header force secure connections to the server. This prevents losing session data stored in cookies. Also prevents users to access website in case the server’s TLS certificate is not trusted. Browser support: IE 11+, Chrome 4+, Firefox 4+, Opera 12+, Safari 7+. Accepts following directives:
max-age Required . The number of seconds that browser should force the connection over HTTPS. includeSubDomains Optional . If present, tells to the browser that the policy applies to current host and to all host’s subdomains. preload Optional . Not part of the specification.
Content-Security-Policy
This header could affect your website in many ways, so be careful when using it. The configuration below allows loading scripts, XMLHttpRequest (AJAX), images and styles from same domain and nothing else. Browser support: Edge 12+, Firefox 4+, Chrome 14+, Safari 6+, Opera 15+
Few notes: IE 10 and 11 supports CSP through the X-Content-Security-Policy header; Safari 5.1 supported through the X-Webkit-CSP header.
Access-Control-Allow-Origin
The Access-Control-Allow-Origin is part of the cross-origin resource sharing specification which we discussed recently.
Public-Key-Pins
The Public Key Pinning Extension for HTTP (HPKP) is a security feature that tells a web client to associate a specific cryptographic public key with a certain web server to prevent man-in-the-middle attacks with forged certificates. Currently, the HPKP header is deprecated and its support was removed.
Referrer-Policy
Controls the value of Referer header sent with the additional requests for resources from a web page. Firefox 36+ and Opera 15+ had a full support of the specification. Edge 12+ and Safari 7.1+ supports the older draft of the spec with never , always , origin and default values. Chrome 21+ does not support same-origin , strict-origin and strict-origin-when-cross-origin values. Valid values are as follow:
«» An empty string is considered to no referrer policy, i.e. referrer fallbacks to policy defined elsewhere. no-referrer Means that no referrer information is sent along the requests. no-referrer-when-downgrade The referrer is sent to requests with better or same security (HTTP to HTTPS, HTTPS to HTTPS, HTTP to HTTP), but not less (HTTPS to HTTP). This is the default policy. same-origin The referrer header is sent only to same-origin requests. A request is with same-origin when the URL scheme, hostname and port of the source and destination matches. origin Browsers will always send the referrer header, but it will contain only the origin. The pathname and query string will be stripped-off. strict-origin The referrer header consists of only the origin and is sent to requests with better or same but not less security. origin-when-cross-origin The referrer is always sent, but contain only the origin if a request is cross-origin. Otherwise, the full URL is sent. strict-origin-when-cross-origin Browsers send only the origin as a referrer to cross-origin requests and the full URL to those with same-origin, but no referrer is sent to less secure destinations. unsafe-url A full URL, without parameters, is sent along both the same-origin and cross-origin requests.
Expect-CT
Certificate Transparency policy means that user-agents, e.g. browsers should block an access to a website with a certificate that is not registered in public CT logs (after October 2017). Omitting the enforce directive will make it work only in report-only mode. In the other side, the report-uri directive is meaningless when used together with the enforce directive.
max-age The time, in seconds, that the user-agent should regard the host received as an Expect-CT Host. report-uri An optional directive that indicates the URI to which the user-agent should report Expect-CT failures. enforce An optional, valueless directive that, if present, signals to the user-agent to block future requests that violate the CT policy.
Feature-Policy
The Feature-Policy header gives a site owners an opportunity to enable and disable specific browser features and APIs. This is a list of currently supported features:
- accelerometer
- ambient-light-sensor
- autoplay
- camera
- cookie
- docwrite
- domain
- encrypted-media
- fullscreen
- geolocation
- gyroscope
- magnetometer
- microphone
- midi
- payment
- picture-in-picture
- speaker
- sync-script
- sync-xhr
- unsized-media
- usb
- vertical-scroll
- vibrate
- vr
NB » Recently, this header was renamed to Permissions-Policy in the spec.
To control the origins use the following values:
* Any origin have an access to this feature. ‘self’ Only the same-origin have an access to this feature. This is the default behavior. ‘none’ None origin have an access to this feature. <origin(s)> Only the specified origins have an access to this feature.
Permissions-Policy
This specification used to be named Feature Policy. This is a list of currently policy-controlled features:
- accelerometer
- ambient-light-sensor
- autoplay
- battery
- camera
- cross-origin-isolated
- display-capture
- document-domain
- encrypted-media
- execution-while-not-rendered
- execution-while-out-of-viewport
- fullscreen
- geolocation
- gyroscope
- magnetometer
- microphone
- midi
- navigation-override
- payment
- picture-in-picture
- publickey-credentials-get
- screen-wake-lock
- sync-script
- sync-xhr
- usb
- vertical-scroll
- web-share
- xr-spatial-tracking
Clear-Site-Data
The Clear-Site-Data header clears browser data for requested origin. The following directives are supported:
«*» (wildcard) clear all types of data «cache» clears browser cache «cookies» clear all browser cookies on entire domain, including subdomains «storage» clear all DOM storage, including localStorage, sessionStorage, IndexedDB, AppCache, WebSQL, Server Workers «executionContexts» reload all browsing contexts
Cross-Origin-Resource-Policy
The HTTP Cross-Origin-Resource-Policy response header conveys a desire that the browser blocks no-cors cross-origin/cross-site requests to the given resource. Supported directives are:
same-site same-origin cross-origin
Cross-Origin-Embedder-Policy
The HTTP Cross-Origin-Embedder-Policy (COEP) response header prevents a document from loading any cross-origin resources that don’t explicitly grant the document permission (using CORP or CORS). Supported directives are:
unsafe-none This is the default value. Allows the document to fetch cross-origin resources without giving explicit permission through the CORS protocol or the Cross-Origin-Resource-Policy header. require-corp A document can only load resources from the same origin, or resources explicitly marked as loadable from another origin.
Cross-Origin-Opener-Policy
The HTTP Cross-Origin-Opener-Policy (COOP) response header allows you to ensure a top-level document does not share a browsing context group with cross-origin documents. Supported directives are:
unsafe-none This is the default value. Allows the document to be added to its opener’s browsing context group unless the opener itself has a COOP of same-origin or same-origin-allow-popups . same-origin-allow-popups Retains references to newly opened windows or tabs which either don’t set COOP or which opt out of isolation by setting a COOP of unsafe-none . same-origin Isolates the browsing context exclusively to same-origin documents. Cross-origin documents are not loaded in the same browsing context.
Big players as Google+, Facebook, Twitter, LinkedIn use the above HTTP headers as an additional layer on a defence of their architecture. So it’s strongly recommended the use of security HTTP headers to make your website safer and resist of attacks. Do you want to know how secure is your website? Let’s find out with a quick scan of your server response using our Headers Inspector tool.
Использование HTTP-заголовков для предупреждения уязвимостей сайта
Поддержка безопасности веб-ресурса — один из важнейших аспектов в его благополучном существовании в Сети и не менее значимая составляющая, чем контент или SEO-оптимизация. Игнорирование текущих или возможных уязвимостей может повлечь серьезные проблемы не только для посетителей, но и для его владельца. Начиная с DDoS-атак и кликджекинга, заканчивая утечкой конфиденциальной информации и распространением вирусов. Впоследствии зараженный и по совместительству вредоносный веб-ресурс наверняка будет заблокирован поисковой системой, браузером или хостингом. Чтобы дать весомый отпор злоумышленникам, познакомимся с одним из эффективных рычагов настройки надежности своего сайта — HTTP-заголовками.
Что такое HTTP-заголовки
HTTP — протокол передачи гипертекста задействован в обмене данными между пользовательским приложением (как правило, браузером) и веб-сервером. Например: формат ресурса, его местонахождение, используемая кодировка, сведения для авторизации и параметры аутентификации. Такое клиент-серверное общение нуждается в обеспечении соответствующих мер, поэтому также существуют заголовки, призванные предотвращать различные кибератаки.
Список заголовков безопасности HTTP и их использование
Теперь, когда понятна суть и известно общее назначение, перейдем непосредственно к практике. Но прежде настоятельно рекомендую позаботиться о бекапе конфигурационного файла, в котором будут создаваться заголовки.
- Nginx — nginx.conf;
- .htaccess;
- PHP — index.php (header.php/head.php) активного шаблона сайта.
Чтобы удостовериться, что в ответ сервера добавлен заголовок, можно воспользоваться специальным сервисом проверки заголовков, обычной проверкой ответа сервера от Яндекс или любым подобным веб-приложением.
Для наглядности рассмотрим пример, где безопасность сайта явно хромает на обе ноги.
Далее рассмотрим заголовки, их специфику и способы применения, после чего повторим проверку сервисом.
HTTP Strict Transport Security (принудительное использование защищенного соединения, HSTS)
Запрещает использование HTTP, активирует форсирование защищенного HTTPS-соединения, автоматически преобразует HTTP-запросы в HTTPS, блокирует попытки пользователя пройти дальше сообщения о проблемах с сертификатом. Отражает попытки перехвата трафика с применением поддельного сертификата.
- max-age — интервал в секундах, в течение которого сайт будет отвечать по защищенному протоколу. Рекомендуется указывать не менее 18-ти недель.
- includeSubDomains — указывается при необходимости распространения на поддомены.
- preload — применяется при необходимости добавления сайта в предопределенный список HSTS.
Nginx – в секции Server
add_header Strict-Transport-Security «max-age=10886400?; includeSubDomains»;
X-Xss-Protection
Предотвращает XSS-атаки путем активации фильтра межсайтового скриптинга.
- 1 — фильтр включен
- 0 — фильтр выключен
- mode=block — если атака зафиксирована, то обработка страницы предотвращается
- report=URL — отсылает на заданный url отчет при фиксировании атаки
Nginx – в секции HTTP
X-Frame-Options
Ограничивает загрузку страниц сайта во фреймах. Снижает уязвимость перед кликджекинг-атаками.
- ALLOW-FROM — разрешена загрузка во фреймах только для указанного url
- SAMEORIGIN — разрешена загрузка страниц через фреймы, при условии, что это происходит в рамках одного домена
- DENY — накладывает полный запрет на загрузку сайта через фреймы сторонних ресурсов
Nginx — в секции Server
X-Content-Type-Options
Препятствует фишинговым атакам, работающих на основе изменения MIME-типов и несанкционированных хотлинков. Даже если запретить пользователям сайта загружать исполняемые файлы, например, с расширением .js, злоумышленник может загрузить изображение или txt-файл на сервер с внедренным в него JavaScript-кодом и обратиться к нему напрямую через url, тем самым запустив его со всеми вытекающими последствиями. Директива всего одна — nosniff.
Nginx – в секции Server
Content-Security-Policy (политика защиты контента, CSP)
Противостоит кликджекингу, попыткам внедрения кода и XSS-атакам. Суть заключается в том, чтобы указать серверу безопасный источник хранения и получения контента, например, скриптов, стилей, изображений и т.п. Загрузка с источников, не указанных в белом списке, блокируется. Поэтому если на вашем веб-ресурсе используется CDN, счетчики метрики и прочие скрипты, использующие внешние подключения, обязательно добавьте их.
- default-src — источники по умолчанию;
- script-src — скрипты;
- object-src — плагины (в т.ч. Flash и Java);
- style-src — стили;
- img-src — изображения;
- media-src — видео и аудио;
- frame-src — фреймы;
- font-src — шрифты;
С полным списком и описанием можно ознакомиться тут.
- если необходимо полностью запретить загрузку контента в рамках одной директивы, применяется — none;
- self — обозначает текущий домен;
- при перечислении url используется пробел.
- Content-Security-Policy: default-src ‘self’;
- Content-Security-Policy: default-src ‘self’; style-src ‘self’ http://domain.ru; script-src http://domain.ru.
Nginx — в секции Server
Referrer-Policy
Зачастую ссылки ведущие с одного ресурса на другой, могут содержать в себе различную информацию, в том числе и конфиденциальную. Особенно это опасно при переходе с HTTPS-соединения на HTTP. Данный заголовок способен предотвратить утечку.
- no-referrer-when-downgrade (рекомендуется) — информация отправляется в том случае, когда уровень безопасности протокола остается неизменным или ведет на более защищенный (HTTP > HTTP, HTTPS > HTTPS или HTTP > HTTPS);
- no-referrer-when-cross-origin — информация отправляется только в том случае, когда уровень безопасности протокола остается неизменным (HTTP > HTTP или HTTPS > HTTPS);
- origin — оставляет только источник документа: https://domain.ru/page.html > https://domain.ru;
- origin-when-cross-origin — если запрос направляет на отличающийся протокол или веб-ресурс, то срабатывает как origin;
- no-referrer — информация не отправляется вместе с запросами.
С полным списком и описанием можно ознакомиться тут.
Nginx — в секции Server
Feature-Policy
Позволяет выборочно подключать или отключать различные функции веб-браузера пользователя при посещении сайта, либо менять их поведение.
- geolocation — определение местоположения;
- speaker — воспроизведение звуков;
- microphone — использование средств аудио выхода;
- fullscreen — контроль над полноэкранным режимом;
- display-capture — захват дисплея.
С полным списком и описанием можно ознакомиться тут.
- запрет в рамках одной директивы — none;
- self — обозначает текущий домен.
Nginx — в секции Server
Что ж, теперь если повторить проверку того же сайта, можно убедиться, что заголовки установлены корректно и работают так, как это необходимо.
Пример конфигурации для файла .htaccess:
В заключение
Теперь вы знаете, как улучшить безопасность своего веб-ресурса, используя HTTP-заголовки. Как правило, сложностей нет, главное — подход с пониманием дела, без спешки, проверяя каждый шаг. Если у вас что-то не получается или просто нет возможности этим заниматься, вы всегда можете обратиться к команде наших специалистов. Мы поможем вашему сайту стать более надежным.