Безопасность iCal-ссылки: что утекает вместе с календарём

Одиннадцать месяцев. Столько моя ссылка на экспорт календаря Airbnb провисела в открытой ветке форума — проиндексированная Google, доступная любому, кто долистал до конца. Я вставил её целиком, чтобы спросить, почему Booking.com не подхватывает фид. Ответили за двадцать минут: слот импорта был в порядке, при копировании в ссылку затесался лишний пробел. Я закрыл вкладку. Ссылка осталась. Это токен без срока действия и без единой строчки в логах доступа — одиннадцать месяцев он отдавал все занятые даты одной из моих квартир любому, кто попросит.

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

Ссылка — это пароль, но относиться к ней так никто не умеет

Каждая площадка с экспортом календаря решает вопрос доступа одинаково лениво: секрет — это сама ссылка. Airbnb выдаёт что-то вида https://www.airbnb.com/calendar/ical/12345678.ics?s=<токен из 32 символов>. Booking.com — https://admin.booking.com/hotel/hoteladmin/ical.html?t=<токен>. Ни логина, ни заголовка, ни подписи, ни белого списка адресов. Запросил ссылку — получил файл.

Это не недосмотр, а единственная схема, которая тут работает: на другом конце стоит импортёр Booking.com, и залогиниться под вами он не может. Вся бесплатная связка календарей через iCal держится на том, что ссылку по расписанию дёргает анонимная машина. В самом протоколе — RFC 5545 — понятия «авторизованный подписчик» просто нет.

Три свойства этого токена делают его хуже пароля:

1. Он не истекает. Пароль, заведённый в 2023-м, хотя бы иногда просят сменить. Ссылка на фид из 2023-го сегодня отдаёт живой актуальный календарь.
2. Логов доступа нет. Airbnb не расскажет, что за прошлый месяц фид скачали 400 раз с адресов, не имеющих отношения к Booking.com. Утечку нельзя обнаружить — её можно только предполагать.
3. Он опознаётся с первого взгляда. Те самые 12345678 в пути — ID вашего объявления. Подставьте его после airbnb.com/rooms/ и получите публичную страницу: фотографии, район, примерный адрес. Фиду не нужно называть вас по имени. Это делает ссылка.

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

Откройте свой фид и прочитайте его

Хватит гадать, что внутри. Это обычный текстовый файл, и открывается он в браузере.

Вставьте ссылку экспорта в адресную строку и нажмите Enter. Дальше одно из двух: браузер скачает файл .ics или покажет полотно текста, начинающееся с BEGIN:VCALENDAR. Если скачал — откройте любым текстовым редактором, это текст, а не бинарник. Блокнот, VS Code, что ближе лежит.

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

BEGIN:VEVENT
DTSTART;VALUE=DATE:20260803
DTEND;VALUE=DATE:20260809
UID:[email protected]
SUMMARY:Reserved
DESCRIPTION:Reservation URL: https://www.airbnb.com/hosting/reservations/details/HMXXXXXXXX
END:VEVENT

Пролистайте файл целиком и ответьте себе на три вопроса:

• Встречается ли имя в SUMMARY? Где-то там сухое Reserved или Not available. Где-то — имя гостя, иногда с первой буквой фамилии.
• Есть ли вообще блок DESCRIPTION и что в нём? У Airbnb были выгрузки, где в этом поле лежала ссылка на бронирование, код подтверждения и последние четыре цифры телефона гостя. Так у вас или нет — зависит от площадки, типа объекта и года. Ровно поэтому файл нужно открыть, а не поверить статье в блоге.
• Насколько далеко он тянется? Обычно вперёд примерно на 12 месяцев. Иногда в выгрузку попадает и прошлое — тогда это уже не график на будущее, а история заселений.

Полторы минуты. Сделайте это для каждого фида, который вы когда-либо экспортировали, на каждой площадке — прежде чем читать дальше.

Что каждая площадка кладёт в файл

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

Booking.com здесь ведёт себя приличнее всех: помечает отрезки занятыми и молчит обо всём остальном. Поэтому импортированный фид Booking физически не может занести данные гостя в Airbnb, даже если бы вам этого захотелось. Проверять надо Airbnb и Vrbo.

Эта асимметрия важна по практической причине. Хост думает про фид, который импортирует, — тот, что заполняет календарь. А риск живёт в фиде, который он экспортирует: настроил один раз, куда-то вставил и больше никогда не открывал.

Пять мест, откуда ссылка уходит наружу

Все утечки, которые я видел или устроил сам, укладываются в этот список.

1. Публичная отладка. Мой случай и самый частый с большим отрывом. Синхронизация встала, вы пишете в чат хостов, на форум или в issue на GitHub — и вставляете ссылку, потому что как иначе вам помогут. Тред переживёт вашу проблему на годы, а Google его проиндексирует. Если страница открытая, а файл текстовый, ищется потом не только ссылка, но и её содержимое.

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

3. Брошенные сервисы. За два года вы попробовали четыре channel manager'а. В каждый вставили ссылку. Три аккаунта заброшены, одну компанию с тех пор купили — и у всех до сих пор лежит рабочий токен. Триальный аккаунт никто не удаляет, да и удаление аккаунта не равно отзыву токена. Отзыв — это только перевыпуск.

4. Общие календари. Подписать Google Календарь на фид — нормально. Поставить этому календарю «Сделать общедоступным» — нет, а это два клика в той же панели настроек. Дальше публичный Google Календарь переопубликует ваш фид уже по новой ссылке, которую создавали не вы.

5. Передача объекта. Ушёл со-хост, сменился клинер, продали квартиру. Все выданные ссылки продолжают работать. Ни в одном чек-листе увольнения нет строки текста, который кто-то однажды вставил в свой инструмент.

Как перевыпустить ссылку на каждой площадке

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

Airbnb. «Календарь» → нужное объявление → «Доступность» → «Синхронизация календарей» → найдите свой экспорт и нажмите «Сбросить ссылку». Старая перестаёт открываться сразу. У всех площадок и сервисов, которые её импортировали, фид становится мёртвым, и большинство из них промолчат вместо предупреждения. Заложите пятнадцать минут на то, чтобы вставить новую ссылку везде, и на следующий день проверьте у каждого получателя дату последнего импорта.

Booking.com. Экстранет → «Календарь и цены» → «Синхронизация календарей». Кнопка сброса на экспорте есть не в каждой сборке экстранета. Если её нет — удалите экспорт и создайте заново, это даёт новый токен; если и этого пути нет, партнёрская поддержка перевыпустит ссылку по заявке, и завести её стоит, а не махнуть рукой. Экспорт Booking несёт меньше всех, но та же ссылка всё равно раскрывает вашу занятость целиком.

Vrbo. «Календарь» → «Настройки» → «Импорт/экспорт». Схема та же: перевыпустить, потом переставить у всех получателей.

Что бы вы ни меняли — запишите, куда ушла новая ссылка. Хосты избегают перевыпуска не из-за клика, а из-за незнания, какие четыре сервиса тихо перестанут синхронизироваться в четверг. Три строчки в том же файле, где лежат ID объявлений, закрывают вопрос навсегда.

После любого перевыпуска сорок восемь часов держите под рукой проверки от двойных броней. Мёртвый слот импорта выглядит точно так же, как рабочий, ровно до момента, когда два гостя забронируют одну неделю: Airbnb тянет импортированные календари каждые 2–4 часа, Booking.com — каждые 2–6, и никто из них не кричит, когда вместо календаря приходит 404.

Когда утечка фида — это инцидент по GDPR

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

Статья 4(12) GDPR относит к утечке персональных данных любое несанкционированное раскрытие данных или доступ к ним — не только кражу и не только взлом. Ссылка на фид, попавшая в открытый тред, — это раскрытие. Дальше вопрос в том, персональные ли это данные, и ответ целиком зависит от того, что вы увидели, открыв файл.

• Только даты, без имён (типичный экспорт Booking.com): занятость идентифицируемого объекта. Само по себе слабо, но в связке с публичным адресом объявления это скорее персональные данные о вас, чем о гостях. Зафиксируйте, перевыпустите ссылку, живите дальше.
• Имена гостей или имена плюс код брони: персональные данные без вариантов. Статья 33 даёт 72 часа с момента, когда вы узнали, на уведомление надзорного органа — если только утечка вряд ли создаёт риск для прав и свобод людей.
• Имена плюс обрывки контактов плюс точные даты проживания: именно эта комбинация разворачивает оценку риска в плохую сторону, потому что рассказывает постороннему, кто и в какие ночи живёт по конкретному адресу.

Две практические ремарки. Статья 33(5) требует документировать каждую утечку и ход рассуждений — включая те, о которых вы решили не сообщать. Достаточно абзаца с датой, важно, чтобы он появился до того, как кто-то спросит. И контролёр данных здесь вы, а не Airbnb: площадка дала функцию экспорта, а куда положить ссылку, решали вы. База по GDPR для хостов разбирает правовое основание и сроки хранения, на которых всё это стоит.

Экспортировать стоит тот фид, которым управляете вы

Структурное решение — вообще перестать раздавать токены, выпущенные площадками.

Поставьте посередине слой, который принадлежит вам. Обе площадки импортируют из вашего фида, и наружу — в сервис, на скриншот, в форум — уходит только эта ссылка. Перевыпуск становится одним действием вместо четырёх, поэтому вы его действительно делаете. В файле оказываются ровно те поля, которые вы решили отдавать: для синхронизации занятости хватает DTSTART, DTEND, UID и SUMMARY со значением Busy — ничего, что превращает график в досье. А когда уходит со-хост, вы меняете одну строку.

Во многом поэтому RentTools устроен именно так: тянет исходные фиды каждые 10 минут, отдаёт минимальный исходящий фид на объект и перевыпускает эту исходящую ссылку по требованию, не трогая настройки Airbnb и Booking.com. Разверните на дроплете за 4 $ или возьмите хостинговый инстанс — в обоих случаях токен, который вы вставляете в чужой софт, вы можете убить сами.

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

Особое мнение

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

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