Почему фрагмент # в URL не попадает в логи сервера

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

Полный адрес делится на три части. Протокол и хост решают, к кому подключается браузер; путь и параметры запроса после вопросительного знака решают, какой ресурс нужен, — и эти две части попадают в строку HTTP-запроса. Символы после решётки называются fragment, по-русски обычно «фрагмент». Изначально они говорили браузеру прокрутить страницу к якорю; позже фронтенд-скрипты читают этот текст локально через location.hash. Сервер его не получает и не должен использовать для маршрутизации или авторизации.

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

Так устроен стандарт URL уже давно: это не частная договорённость одного сайта и не «сервер пообещал не смотреть». «Видит ли сервер» здесь значит: после терминации TLS может ли исходный сервер или обратный прокси под вашим контролем прочитать это поле из HTTP-запроса. Речь не про скомпрометированное устройство, расширение, которое читает страницу, или сохранённый скриншот.

При создании текущая вкладка через Web Crypto генерирует случайный ключ, шифрует текст алгоритмом AES-256-GCM и отдаёт шифротекст серверу. Полученный номер попадает в ?id=; ключ дописывается только после #.

Страница чтения открыта получателю. Когда он открывает s.html?id={id}#{key}, браузер сначала запрашивает шифротекст или статус по id, затем расшифровывает ключом из фрагмента, который остаётся на устройстве. После числа прочтений, заданного при создании, сервер удаляет шифротекст, и ссылку больше не прочитать. Получателю тоже не нужна регистрация. Сама страница чтения — временный просмотр шифротекста, не вход в индекс сайта; чтобы понять возможности продукта, вернитесь на страницу создания или к шагам проверки в этой статье.

Ключ во фрагменте закрывает слой «логи сервера и строка запроса». Он не закрывает вопрос «кому вы отправили полную ссылку». Чаты, почта и системы заявок сохраняют весь адрес, который вы вставили. У кого полная ссылка — у того и номер, и ключ. Burn-Link ограничивает срок жизни шифротекста и число прочтений на стороне сервера, а не то, сделает ли получатель скриншот или перешлёт дальше.

Чем это отличается от схемы с параметрами запроса

Некоторые одноразовые ссылки кладут материал для расшифровки в ?k=. Так проще, но при каждом открытии ключ попадает в строку запроса, и CDN, WAF и журналы доступа исходного сервера могут сохранить копию. Фрагмент стоит одной решётки, а взамен даже полная запись URL на стороне хостинга не содержит половины, которой открывается шифротекст. Цена в том, что получателя нужно попросить скопировать ссылку целиком, а не только часть до решётки: без # и того, что за ним, страница чтения получит шифротекст и не сможет открыть его локально.

Поэтому статья не называет Burn-Link «менеджером паролей» или «сейфом, из которого можно всё вернуть». У UsePwd нет аккаунтов, нет хранилища паролей и нельзя вернуть пароль по пользователю. Ссылка потеряна, фрагмент обрезан или число прочтений исчерпано — сервер не восстановит открытый текст за вас. Кто мы такие — на странице О сервисе.

Если секрет нужно прочитать ограниченное число раз и обе стороны могут открыть браузер, используйте одноразовую ссылку: открытый текст шифруется локально, номер идёт в ?id=, ключ — после #, регистрация не нужна. После создания один раз сверьте в панели Network: тело POST — шифротекст, в URL GET нет фрагмента. Если на самом деле нужны долгое хранение, синхронизация устройств или восстановление, это уже за пределами сайта: возьмите отдельный менеджер паролей и не считайте UsePwd системой аккаунтов.

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

Насколько стоек сам пароль — отдельный вопрос. Случайную строку длиной 6–128 символов даёт генератор паролей; чтобы локально оценить стойкость и сверить с открытым списком слабых паролей из утечек, который прилагается к странице, откройте проверку пароля. Это не поиск по всей сети, проверяемая строка на сервер не уходит. Перед отправкой ссылки или текста заявки уберите параметры отслеживания или замаскируйте данные на странице убрать UTM. Эти страницы, как и эта статья, работают без регистрации. Справа в шапке только переключатель языка.