Журнал безпеки.

Внутрішня перевірка перед запуском програми

15 липня 2026 року ми розпочали внутрішню перевірку безпеки CreateYourVPN. Виправлення, які ми завершили та перевірили повторно, опубліковано нижче; решта з'являтимуться в міру розгортання та підтвердження.

Додано захист від небезпечної cross-origin конфігурації

Поточна production-конфігурація не дозволяла довільні origins, проте код допускав небезпечне поєднання параметрів у разі помилки оператора. Тепер така конфігурація відхиляється під час запуску і покрита автоматичним тестом.

Скорочено публічну поверхню production API

Інтерактивна технічна документація API була доступна без автентифікації. Це не давало доступу до захищених даних, але полегшувало вивчення внутрішньої структури API. У production документацію тепер вимкнено, а для розробки вона лишається доступною в ізольованому середовищі.

Розділено криптографічні ключі платформи за призначенням

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

Гарантовано очищення керуючого ключа після видалення сервера

Очищення зашифрованого керуючого ключа виконувалося після фонових мережевих операцій і могло не повторитися в разі їхнього збою. Ми відокремили очищення ключа від мережевого каскаду й додали гарантоване повторення. Сценарії недоступного сервера та переривання процесу покрито тестами.

Видалено невикористовуваний спосіб авторизації партнерського API

API підтримував додатковий cookie-шлях авторизації, який не потрібен поточній server-side архітектурі. Підтвердженої міжсайтової атаки в production не виявлено, проте зайвий шлях збільшував поверхню майбутніх помилок. API переведено на один явно визначений спосіб авторизації й покрито негативними тестами.

Обмежено доступ до панелі керування інфраструктурою

Зовнішній дослідник повідомив, що адміністративний інтерфейс керування інфраструктурою відповідав із публічної мережі. Інтерфейс був захищений автентифікацією, ознак несанкціонованого доступу не виявлено. Звіт прийнято, доступ обмежено.

Зараз інтерфейс доступний лише з дозволених адрес, вимоги до автентифікації посилено, задіяні компоненти оновлено. Результат перевірено із зовнішньої мережі. Додатково переглянуто публічно доступну поверхню та додано її регулярну перевірку. Винагороду виплачено за найвищим рівнем.

Адреси користувачів вітрин більше не зберігаються

Людина вводить свій email, щоб увійти до вітрини партнера, але в нас ця адреса не осідає: лист із кодом іде, і адреса одразу видаляється. Обліковий запис упізнається за необоротним відбитком, з якого адресу не відновити, а ім'я запису її не містить.

Користувач може сам скинути своє посилання на підписку

Посилання на підписку — це секрет: той, хто його має, отримує такий самий доступ, як і власник. Користувач може скинути його сам в особистому кабінеті — попереднє посилання перестає працювати, а доступи за ним видаються заново. Закрите так посилання лишається закритим, зокрема й після відновлення даних із резервної копії.

Security-заголовки на сторінках вітрин

Вітрини партнерів не віддавали security-заголовків, які панель і API віддавали давно, — зокрема того, що забороняє чужим сайтам показувати сторінку у фреймі. Прочитати так дані акаунта чи сесію було неможливо. Тепер повний набір іде з кожною відповіддю вітрини, а твердження SR-15 називає кожен фронтенд, який ми розміщуємо.

Керування сесіями та надсилання кодів входу

За звітами зовнішнього дослідника ми переглянули дві суміжні ділянки: життєвий цикл партнерської сесії та шлях листа з кодом входу. Доступу до акаунтів, даних партнерів чи трафіку користувачів жодна зі знахідок не давала.

Зміни в надсиланні кодів входу розгорнуто та перевірено. Окрема дія «вийти на всіх пристроях» готується; до її появи вихід з акаунта завершує поточну сесію.