HSTS убрали, а браузер требует HTTPS: где осталась политика

Удаление HSTS-заголовка не отменяет уже полученную браузером политику: она сохраняется до предусмотренного истечения. Требование HTTPS также может прийти от родительского имени с includeSubDomains или preload. Сначала восстановите рабочий HTTPS и установите источник правила, а не просите посетителей отключать защиту.

Текущий ответ и сохранённое знание браузера

В справке MDN по Strict-Transport-Security описано сохранение правила после безопасного ответа. При следующем обращении браузер может применить это знание ещё до обычного HTTP-перехода. Поэтому отсутствие заголовка в новом ответе не доказывает отсутствие действующей политики.

Это отличается от серверной переадресации. Один лишь переход на HTTPS не устанавливает его причину: нужно понять, какое действие выполнил браузер и какой ответ действительно получен. Иначе исправление 301 на сервере может не затронуть сохранённое требование клиента.

Карта возможных источников

Таблица — учебная схема для владельца сервиса, а не сведения о политике домена пользователя. Разные источники могут действовать одновременно; проверка только одного заголовка на одном адресе оставляет остальные вопросы открытыми.

Почему ожидание от даты включения может быть неверным

MDN поясняет, что каждый полученный HSTS-заголовок обновляет срок, прибавляя max-age к моменту получения. Постоянное значение не означает, что правило обязательно закончится через такой интервал от первого включения. Новые ответы могут снова отодвигать истечение.

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

Что означает max-age=0

RFC 6797 определяет нулевое значение как сигнал удалить сохранённую политику соответствующего HSTS-имени. Важна доставка такого сигнала по безопасному соединению. Отправка того же заголовка через незащищённый HTTP не является способом надёжно отменить правило.

Нельзя приравнивать изменение одной записи к исчезновению всех причин требования HTTPS. Родительская область и собственные правила других имён требуют своего рассмотрения. Сначала составьте карту источников, затем выбирайте согласованное изменение, если оно действительно необходимо.

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

Родитель и поддомены

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

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

Почему preload не откатывается мгновенно

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

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

Как сравнивать старое и новое состояние клиента

В согласованной тестовой среде можно сравнить профиль с известной историей и подготовленный новый профиль. Разница помогает уточнить гипотезу о сохранённой политике, но не является доказательством, что preload отсутствует: он может уже входить в сам клиент.

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

План приёмки изменения

1. Восстановите корректный HTTPS для затронутых имён.
2. Зафиксируйте текущие ответы и отделите серверную переадресацию от поведения клиента.
3. Составьте карту собственного HSTS, родительского includeSubDomains и preload.
4. Согласуйте изменение нужной области и способ безопасного получения клиентом.
5. Проверьте подготовленные клиентские сценарии без обхода сертификатных ошибок.
6. Наблюдайте получение изменений, отдельно учитывая доставку preload и обновления браузеров.

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

Приёмка должна отвечать на вопрос, откуда клиент получает требование и как сервис остаётся доступным безопасно. Исчезновение заголовка в одном просмотренном ответе этого ещё не доказывает.