Контент тайп что это

Контент тайп что это

Поле заголовка ‘Content-Type’

Хотя многие параметры (модификаторы подтипов) имеют смысл лишь для конкретного типа, некоторые все же являются глобальными в том смысле. что они применимы ко всем типам (например, параметр «boundary» применим только с типом «multipart», а параметр «charset» может использоваться с несколькими типами).

Пока имен типов только семь, и пока этого достаточно. Кроме того, предполагается, что расширение существующего набора поддерживаемых типов данных будет производиться засчет введения новых подтипов этих изначально определенных типов данных. В будущем добавление имен типов верхнего уровня может быть произведено только при принятии новой версии стандарта MIME. Если по какой-либо другой причине в существующей версии используется незарегестрированный тип содежимого, ему должно быть дано имя, начинающееся с «X-«, чтобы подчеркнуть его нестандартный статус и заранее предупредить конфликт с официальным именем типа, которое может быть введено позднее.

Правильное заполнение поля Content-Type:

Здесь набор специальных символов отличается от набора, определенного в RFC 822 только наличием символов «/», «?», «=» и отсутствием символа «.».

Существует два приемлимых механизма для введения новых подтипов для поля Content-Type:

Семь предопределенных типов верхнего уровня, более детально, представляют собой следующее:

По умолчанию, письма, как и в стандарте RFC 822 пишутся простым (неразмеченным) текстом в языковой кодировке US-ASCII, что по спецификации MIME может быть описано как «Content-type: text/plain; charset=us-ascii». Это значение полагается, если поле Content-type не определено. Поэтому почтовая программа получателя может неверно истолковать содержимое письма, если при отправке не было указано поле Content-type, но на самом деле текст письма имеет другую кодировку или даже тип.

При отсутствии поля Content-type или поля MIME-Version в заголовке MIME-письма нельзя быть точно уверенным, что письмо имеет языковую кодировку именно US-ASCII, поскольку могут еще встречаться почтовые программы, не использующие соглашения MIME. Но хотя возможно, что письмо, не содержащее в заголовке полей MIME-Version и Content-Type, может содержать все, что угодно, например, юниксовский tar-архив, сжатый gzip’ом и обработаный uuencode, все же, создателям почтовых программ рекомендуется оставлять этот факт без внимания и ориентироваться на значение по умолчанию, т.е. «text/plain; charset=us-ascii».

Источник

HTTP заголовки | Тип содержимого

Заголовок Content-Type используется для указания типа мультимедиа ресурса. Тип носителя — это строка, отправляемая вместе с файлом с указанием формата файла. Например, для файла изображения его тип носителя будет таким, как image / png или image / jpg и т. Д.

В ответ он сообщает о типе возвращаемого контента клиенту. Браузер узнает о типе контента, который он должен загрузить на компьютер. Каждый раз, когда его байтовый поток файла, который получают браузеры, с помощью заголовка Content-type, браузер будет делать что-то, известное как сниффинг MIME, то есть он будет проверять поток, который он получает, и затем соответствующим образом загружает данные.

Синтаксис:

Директивы: в заголовках HTTP есть три директивы Content-type.

Пример. В этом примере показано, как изображения читаются браузером с настройкой заголовка типа контента и без него.

header( ‘Content-type: image/jpeg’ ); // с заголовком Тип содержимого

Выход :

Теперь, не используя заголовок Content-type, мы получим содержимое изображения в байтах, поэтому оно нам не нужно.

Здесь ясно видно, что, применяя информацию заголовка Content-type, сообщает браузеру, тип ответа, который он получает от сервера.

Все возможные значения заголовка HTTP Content-type:

Поддерживаемые браузеры: браузеры, совместимые с заголовками HTTP, Content-type перечислены ниже:

Источник

Полное руководство по настройке HTTP-заголовков для безопасности

Компании, продающие «системы показателей безопасности», сейчас на подъеме, их влияние в сфере корпоративных продаж растет. К тому же есть те, кого низкий рейтинг безопасности у продавцов смущает, и те, кто хотя бы однажды, глядя на рейтинг, отказался от покупки, — я с такими людьми общался.

Я посмотрел, как эти компании вычисляют показатели безопасности других компаний. Оказалось, они смотрят на сочетание использования НТТР-заголовка для безопасности и репутации IP-адресов.

Репутация IP-адреса основывается на данных черных списков и списков спамеров в сочетании с данными о владельце общедоступного IP-адреса. Она, в принципе, должна быть чистой, если ваша компания не рассылает спам и в состоянии быстро определить и остановить вредоносное внедрение. Использование заголовка безопасности НТТР вычисляется аналогично тому, как работает Observatory от Mozilla.

Таким образом, рейтинг большинства компаний, в основном, определяется заголовками, включенными на общедоступных веб-сайтах для безопасности.

Настроить заголовок правильно — это недолго (серьезной проверки не потребуется), но это улучшит безопасность сайта и поможет не растерять покупателей, для которых безопасность — не пустой звук

В ценности упомянутой методики проверки я сомневаюсь, к том же ценник за услугу выставлен заоблачный. Вряд ли компании-поставщики этой услуги способны определить безопасность ресурса с заявленной точностью. Впрочем, ситуация лишний раз подчеркивает, как важно сесть и уделить время тому, чтобы включить и настроить правильные заголовки.

В этой статье я буду говорить о наиболее часто проверяемых заголовках, для каждого посоветую значения безопасности и приведу пример настройки. В конце дам примеры настройки для распространенных приложений и веб-серверов.

Важные заголовки для безопасности

Content-Security-Policy

CSP применяется, чтобы предотвращать межсайтовый скриптинг — путем определения, какие ресурсы могут быть загружены. Из всего списка этот заголовок отнимет больше остальных времени на создание и правильную поддержку, а еще больше других подвержен рискам. Разрабатывая CSP, тщательно его проверяйте — если вдруг заблокируете используемый вами же источник, то нарушите функциональность собственного сайта.

Для предварительной версии можно использовать замечательный инструмент — расширение для браузера Mozilla, Laboratory CSP. Установите его в браузере, тщательно изучите сайт, для которого хотите создать CSP, а после используйте сгенерированную CSP на своем сайте. В идеале, нужно еще переработать JavaScript, так что можно удалить директиву «unsafe inline».

CSP может показаться сложной и сбить с толку, поэтому, если хотите углубиться в тему, посетите официальный сайт.

Предварительно можно настроить CSP так (на боевом сайте она, скорее всего, потребует множества модификаций). Добавьте в каждый раздел вашего сайта домены.

Strict-Transport-Security

Этот заголовок сообщает браузеру, что на сайт заходить можно только по протоколу HTTPS — всегда включайте его, если на вашем сайта активирован HTTPS. Включите его на всех используемых субдоменах, если таковые имеются.

X-Content-Type-Options

Благодаря этому заголовку браузеры придерживаются типов MIME, установленных приложением, что помогает предотвратить часть атак с межсайтовым скриптингом.

Также он снижает риск неожиданного поведения приложения, когда браузер неверно «угадывает» тип контента на сайте — например, если разработчик обозначает страницу «HTML», а браузер видит JavaScript и пытается отрисовать страницу соответственно. Также благодаря этому заголовку браузер всегда держится установленных сервером MIME-типов.

Cache-Control

Этот будет позаковыристее прочих, потому что для разных типов контента вам наверняка нужны разные политики кэширования.

Никакая деликатная информация — вроде страницы пользователя или страницы оплаты товара — не должна кэшироваться. Одна из причин для этого — чтобы другой пользователь компьютера не нажал кнопку «назад», не прочел историю и не увидел личных данных другого пользователя.

Впрочем, кэшировать можно и нужно те страницы, которые обновляются редко, например статические ресурсы (картинки, файлы CSS и JS). Кэширование можно настроить на постраничной основе, или используя regex в настройках сервера.

Expires

Этот заголовок устанавливает время, на которое текущий запрос сохраняется в кэше. Он игнорируется, если включен заголовок Cache-Control max-age, так что мы включаем его только на случай, если его проверяет простенький сканер — без учета контроля кэширования.

Мы предполагаем, что в целях безопасности браузер не кэширует ничего, так что дата в заголовке всегда будет в прошлом.

X-Frame-Options

Этот заголовок разрешает отображение сайта в iFrame.

Поместив ваш веб-сайт в iFrame, вредоносный ресурс получает возможность произвести кликджекинг атаку — запустив некий JavaScript, который обманом вынудит пользователя кликнуть по iFrame, а после начнет взаимодействовать с ресурсом от его, пользователя, имени (то есть человек кликнет по вредоносной ссылке или кнопке, даже не подозревая об этом!).

Этот заголовок всегда надо настраивать на отказ, исключение — если вы намеренно используете фреймы. Тогда заголовок нужно настраивать на тот же источник. Если вы по умолчанию используете фреймы с другим сайтом, занесите сторонний домен в белый список.

Следует также отметить, что этот заголовок замещается директивой CSP frame-ancestors. Я его рекомендую пока включать, но только для того, чтобы заткнуть инструменты для проверки заголовков, в будущем от него скорее всего избавятся.

Access-Control-Allow-Origin

Этот заголовок сообщает браузеру, внешний код каких посторонних сайтов имеет право делать запросы к определенной странице. Настройки по умолчанию обычно правильные, но если надо — можно и поменять.

Например, сайт А содержит некий JavaScript, который хочет сделать запрос к сайту В. Сайт В должен ответить на этот запрос — если заголовок разрешает сайту А сделать запрос. Если нужно настроить множество источников, подробности на странице на MDN.

Тут можно слегка запутаться, поэтому я составил схему — проиллюстрировать, как работает этот заголовок:

Поток данных с Access-Control-Allow-Origin

Set-Cookie

Убедитесь, что ваши cookies устанавливаются только через протокол HTTPS (с шифрованием), и что к ним нет доступа через JavaScript. Эти файлы можно посылать, только если ваш сайт тоже поддерживает HTTPS, как и должно быть. Всегда нужно выставлять вот такие флаги:

Пример определения Cookie:

X-XSS-Protection

Этот заголовок приказывает браузеру прервать выполнение обнаруженных атак межсайтового скриптинга. Включая его, вы не сильно рискуете, но перед запуском в производственную среду все равно протестируйте.

Пример настроек веб-сервера

Вообще, в настройках сервера лучше всего добавлять заголовки на весь сайт. Исключение — файлы cookie, поскольку они определяются в самом приложении.

Советую, прежде чем добавить на сайт заголовки, сперва свериться с Observatory или вручную заглянуть в заголовки — проверить, какие уже установлены. Некоторые движки сайтов и сервера самостоятельно все установят, поэтому просто реализуйте нужные вам заголовки или измените те, которые в этом нуждаются.

Конфигурация Apache

Конфигурация Nginx

Настройка заголовка уровня приложения

Если у вас нет доступа к веб-серверу или требования к настройке заголовков сложные, то вам наверняка придется настроить их в самом приложении. Обычно для всего сайта это осуществляется с помощью промежуточного ПО, или на основе однократной установки заголовков при каждом запросе.

Для краткости в каждый пример я включил только по одному заголовку. Вы же добавляйте по тому же способу все, которые нужны.

Добавьте global mount path:

Java и Spring

У меня мало опыта работы со Spring, но у Baeldung есть отличное руководство по настройке заголовков в Spring.

Я не знаком с разнообразными средами PHP. Ищите промежуточное ПО для запросов. Для единичного запроса все просто.

Python / Django

Django включает настраиваемое промежуточное ПО для обеспечения безопасности, которое выполнит за вас все эти настройки. Активируйте сначала их.

Ответы некоторых страниц можно трактовать как словарь. В Django есть особый способ работы с кэшированием, и если хотите настроить заголовки кэширования таким образом, с ним надо ознакомиться.

Выводы

Настройка заголовков — процесс относительно простой и быстрый, зато дает прирост уровня безопасности сайта — в плане защиты данных, от межсайтового скриптинга и кликджекинга.

В будущем вы оградите себя от срыва сделок, потому что ваш рейтинг безопасности останется на уровне. Практика его оценки на основе рассмотренных мной параметров набирает обороты, и мне кажется, ее роль в ближайшие годы в сфере продаж только усилится.

Дайте знать, если я упустил какой-то важный заголовок!

Источник

Откуда берется заголовок Content-Type: nginx + php-fpm

Rocket science не будет. Если вы используете php-fpm, то скорее всего в связке с nginx. Простой вопрос: как в PHP получить значения HTTP заголовков запроса клиента?

Как в PHP получить значения HTTP заголовков входящего запроса?

Согласитесь звучит не очень обнадеживающе? Складывается ощущение, что это переменные Шрёдингера. На странице документации приводится ответ на первый вопрос.

Ок, вроде бы всё просто, хоть на странице документации и не сказано про CONTENT_TYPE (правда есть небольшая подсказка комментария 2013 года), попробуем получить значение по аналогии.

К сожалению, такого ключа в массиве нет.

Ну да ладно, давайте посмотрим спецификацию CGI/1.1.

4.1.3. CONTENT_TYPE
If the request includes a message-body, the CONTENT_TYPE variable is
set to the Internet Media Type [6] of the message-body.

There is no default value for this variable. If and only if it is
unset, then the script MAY attempt to determine the media type from
the data received. If the type remains unknown, then the script MAY
choose to assume a type of application/octet-stream or it may reject
the request with an error (as described in section 6.3.3).

The server MUST set this meta-variable if an HTTP Content-Type field
is present in the client request header. If the server receives a
request with an attached entity but no Content-Type header field, it
MAY attempt to determine the correct content type, otherwise it
should omit this meta-variable.

Мы узнали ответ на второй вопрос.

Перейдём к 3-му вопросу, продолжив чтение спецификации.

4.1.18. Protocol-Specific Meta-Variables

The server SHOULD set meta-variables specific to the protocol and
scheme for the request. Interpretation of protocol-specific
variables depends on the protocol version in SERVER_PROTOCOL. The
server MAY set a meta-variable with the name of the scheme to a
non-NULL value if the scheme is not the same as the protocol. The
presence of such a variable indicates to a script which scheme is
used by the request.

Meta-variables with names beginning with «HTTP_» contain values read
from the client request header fields, if the protocol used is HTTP.
The HTTP header field name is converted to upper case, has all
occurrences of «-» replaced with «_» and has «HTTP_» prepended to
give the meta-variable name. The header data can be presented as
sent by the client, or can be rewritten in ways which do not change
its semantics. If multiple header fields with the same field-name
are received then the server MUST rewrite them as a single value
having the same semantics. Similarly, a header field that spans
multiple lines MUST be merged onto a single line. The server MUST,
if necessary, change the representation of the data (for example, the
character set) to be appropriate for a CGI meta-variable.

The server is not required to create meta-variables for all the
header fields that it receives. In particular, it SHOULD remove any
header fields carrying authentication information, such as
‘Authorization’; or that are available to the script in other
variables, such as ‘Content-Length’ and ‘Content-Type’. The server
MAY remove header fields that relate solely to client-side
communication issues, such as ‘Connection’.

А вот и ответ на 3-ий вопрос.

Допустим мы решили поднять nginx + php-fpm через docker-compose

Примерно так будет выглядеть nginx конфиг app.conf

.

И последний вопрос: Как остальные HTTP заголовки, например User-Agent попадают от nginx к php-fpm?

Всё просто, документация nginx даёт ответ.

Parameters Passed to a FastCGI Server

HTTP request header fields are passed to a FastCGI server as parameters. In applications and scripts running as FastCGI servers, these parameters are usually made available as environment variables. For example, the “User-Agent” header field is passed as the HTTP_USER_AGENT parameter. In addition to HTTP request header fields, it is possible to pass arbitrary parameters using the fastcgi_param directive.

Заметьте, здесь сказано, что HTTP заголовки передаются в приложение как HTTP_*. Но на самом деле два заголовка Content-Type и Content-Length, передаются по другому. Я бы назвал это ошибкой документации, но в ней есть слово usually, поэтому не будем придираться.

Выводы

2) Я не знаю причину почему CGI выделил логику заголовков Content-Type/Content-Length. Возможно, для этого была весомая причина. Но результатом является куча неправильного кода программистов.

Например, на stackoverflow советуют вот так получить все HTTP заголовки

Как не сложно заметить, заголовки Content-Type/Content-Length данный код не вернет. При этом ответ имеет 350+ лайков.

Похожий код можно найти и в документации php

Источник

Памятка и туториал по HTTP-заголовкам, связанным с безопасностью веб-приложений

Доброго времени суток, друзья!

В этой статье я хочу поделиться с вами результатами небольшого исследования, посвященного HTTP-заголовкам, которые связаны с безопасностью веб-приложений (далее — просто заголовки).

Сначала мы с вами кратко разберем основные виды уязвимостей веб-приложений, а также основные виды атак, основанные на этих уязвимостях. Далее мы рассмотрим все современные заголовки, каждый — по отдельности. Это в теоретической части статьи.

Исходный код приложений находится здесь.

Демо Heroku-приложения можно посмотреть здесь, а Netlify-приложения — здесь.

Основными источниками истины при подготовке настоящей статьи для меня послужили следующие ресурсы:

Заголовки безопасности

Все заголовки условно можно разделить на три группы.

Заголовки для сайтов, на которых обрабатываются чувствительные (sensitive) данные пользователей

Заголовки для всех сайтов

Заголовки для сайтов с продвинутыми возможностями

Под продвинутыми возможностями в данном случае понимается возможность использования ресурсов сайта другими источниками (origins) или возможность встраивания или внедрения (embedding) сайта в другие приложения. Первое относится к сервисам вроде CDN (Content Delivery Network — сеть доставки и дистрибуции содержимого), второе к сервисам вроде песочниц — специально выделенные (изолированные) среды для выполнения кода. Под источником понимается протокол, хост, домен и порт.

Угрозы безопасности, существующие в вебе

Защита сайта от внедрения кода (injection vulnerabilities)

XSS может предоставить атакующему полный доступ к пользовательским данным, которые обрабатываются приложением, и к другой информации в пределах источника.

Традиционными способами защиты от XSS являются: автоматическое экранирование шаблонов HTML с помощью специальных инструментов, отказ от использования небезопасных JavaScript API (например, eval() или innerHTML ), хранение данных пользователей в другом источнике и обезвреживание или обеззараживание (sanitizing) данных, поступающих от пользователей, например, через заполнение ими полей формы.

Изоляция сайта

Открытость веба позволяет сайтам взаимодействовать друг с другом способами, которые могут привести к нарушениям безопасности. Это включает в себя отправку «неожиданных» запросов на аутентификацию или загрузку данных из приложения в документ атакующего, что позволяет последнему читать или даже модифицировать эти данные.

Наиболее распространенными уязвимостями, связанными с общей доступностью приложения, являются кликджекинг (clickjacking), межсайтовая подделка запросов (Cross-Site Request Forgery, XSRF), межсайтовое добавление или включение скриптов (Cross-Site Script Inclusion, XSSI) и различные утечки информации между источниками.

Безопасность сайтов со сложным функционалом

Шифрование исходящего трафика

Недостаточное шифрование передаваемых данных может привести к тому, что атакующий, в случае перехвата этих данных, получит информацию о взаимодействии пользователей с приложением.

Неэффективное шифрование может быть обусловлено следующим:

Перейдем к рассмотрению заголовков.

Content Security Policy (CSP)

XSS — это атака, когда уязвимость, существующая на сайте, позволяет атакующему внедрять и выполнять свои скрипты. CSP предоставляет дополнительный слой для отражения таких атак посредством ограничения скриптов, которые могут выполняться на странице.

Пример использования nonce-based CSP:

Использование CSP

Обратите внимание: CSP является дополнительной защитой от XSS-атак, основная защита состоит в обезвреживании данных, вводимых пользователем.

nonce — это случайное число, которое используется только один раз. Если у вас нет возможности генерировать такое число для каждого ответа, тогда лучше использовать hash-based CSP.

Генерируем nonce на сервере для скрипта в ответ на каждый запрос и устанавливаем следующий заголовок:

Затем в разметке устанавливаем каждому тегу script атрибут nonce со значением строки :

В данном случае можно использовать только встроенные скрипты, поскольку большинство браузеров в настоящее время не поддерживает хеширование внешних скриптов.

В рассматриваемом заголовке можно использовать следующие директивы:

Возможные значения директив для нестрогого режима CSP :

Trusted Types

Включаем Trusted Types для опасных приемников DOM :

Разумеется, Trusted Types можно комбинировать с другими директивами CSP :

Директива require-trusted-types-for ‘script’ делает использование доверенного типа обязательным. Любая попытка использовать строку в небезопасном API завершится ошибкой.

Подробнее о Trusted Types можно почитать здесь.

X-Content-Type-Options

Когда вредоносный HTML-документ обслуживается вашим доменом (например, когда изображение, загружаемое в сервис хранения фотографий, содержит валидную разметку), некоторые браузеры могут посчитать его активным документом и разрешить ему выполнять скрипты в контексте приложения.

X-Frame-Options

Полностью запрещаем внедрение:

Разрешаем создание фреймов только на собственном сайте:

Обратите внимание: по умолчанию все документы являются встраиваемыми.

Cross-Origin-Resource-Policy (CORP)

Атакующий может внедрить ресурсы вашего сайта в свое приложение с целью получения информации о вашем сайте.

Обратите внимание: ресурсы все равно будут доступны для загрузки, поскольку CORP ограничивает только внедрение этих ресурсов в другие источники.

same-site предназначен для ресурсов, которые используются не только доменом (как в случае с same-origin ), но и его поддоменами.

Cross-Origin-Opener-Policy (COOP)

Значение same-origin рассматриваемого заголовка позволяет полностью запретить открытие сайта в других источниках.

Значение same-origin-allow-popups также защищает документ от открытия в поп-апах других источников, но позволяет приложению взаимодействовать с собственными попапами.

unsafe-none является значением по умолчанию, оно разрешает открытие сайта в виде поп-апа в других источниках.

Мы можем получать отчеты от COOP :

Cross-Origin Resource Sharing (CORS)

CORS — это не заголовок, а механизм, используемый браузером для предоставления доступа к ресурсам приложения.

По умолчанию браузеры используют политику одного источника или общего происхождения, которая запрещает доступ к таким ресурсам из других источников. Например, при загрузке изображения из другого источника, даже несмотря на его отображение на странице, JavaScript-код не будет иметь к нему доступа. Провайдер ресурса может предоставить такой доступ через настройку CORS с помощью двух заголовков:

Использование CORS

Начнем с того, что существует два типа HTTP-запросов. В зависимости от деталей запроса он может быть классифицирован как простой или сложный (запрос, требующий отправки предварительного запроса).

Критериями простого запроса является следующее:

Все остальные запросы считаются сложными.

Перед сложным запросом выполняется предварительный. Он выполняется методом OPTIONS для определения того, может ли быть отправлен основной запрос:

Cross-Origin-Embedder-Policy (COEP)

Полная межсайтовая изоляция приложения

Изоляция с отчетами о блокировках

HTTP Strict Transport Security (HSTS)

Другие заголовки

Referrer-Policy

Clear-Site-Data

Заголовок Clear-Site-Data запускает очистку хранящихся в браузере данных (куки, хранилище, кеш), связанных с источником. Это предоставляет разработчикам контроль над данными, локально хранящимися в браузере пользователя. Данный заголовок может использоваться, например, в процессе выхода пользователя из приложения (logout) для очистки данных, хранящихся на стороне клиента.

Permissions-Policy

Данный заголовок является заменой заголовка Feature-Policy и предназначен для управления доступом к некоторым продвинутым возможностям.

Спецификация рассматриваемого заголовка находится в статусе рабочего черновика, поэтому его поддержка оставляет желать лучшего:

Перейдем к практической части.

Разработка Express-приложения

Создаем директорию для проекта, переходим в нее и инициализируем проект:

Формируем структуру проекта:

Иконку можно найти здесь.

Набросаем какой-нибудь незамысловатый код.

Добавляем стили в public/style.css

В public/script.js мы делаем следующее:

Определяем в package.json команды для запуска серверов:

Приступаем к реализации сервера.

Большинство заголовков можно определить сразу:

Также добавим заголовок Expect-CT :

Блокируем доступ к камере, микрофону, информации о местонахождении и Payment Request API :

Обратите внимание: все директивы должны быть указаны в одну строку без переносов. Мы не определяем директивы для стилей и шрифтов, поскольку они загружаются из других источников.

Также обратите внимание, что мы не используем nonce для скриптов, поскольку мы не рендерим разметку на стороне сервера, но я приведу соответствующий код.

Деплой Express-приложения на Heroku

Создаем удаленный репозиторий на Heroku :

Инструкцию по развертыванию приложения на Heroku можно найти здесь.

Перейдите по указанному адресу и проверьте работоспособность приложения.

Получаем рейтинг приложения:

Получаем результаты оценки приложения (нас интересует первая оценка — Security score ):

Похоже, мы все сделали правильно. Круто!

Деплой приложения на Netlify

Можно запустить сервер для разработки (это необязательно):

Разворачиваем приложение в тестовом режиме:

Разворачиваем приложение в продакшен-режиме:

Инструкцию по развертыванию приложения на Netlify можно найти здесь.

Возвращаемся на Security Headers и WebPageTest и проверяем, насколько безопасным является наше Netlify-приложение:

Кажется, у нас все получилось!

Заключение

Надеюсь, что вы не зря потратили время. Благодарю за внимание и хорошего дня!

Источник