Перевірте сайт перед оплатою або входом

Ні. Він робить обмежену зовнішню перевірку публічної головної сторінки та DNS-записів, як звичайний браузер.

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

Сайт може обмежувати автоматичні запити або реєстр домену може не повертати частину довідкових даних. Ми не намагаємося обходити такий захист.

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

Рекомендується: Налаштуйте чинний сертифікат і відкриття всіх сторінок через HTTPS; після цього перевірте сайт у кількох браузерах.

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

Рекомендується: Перевірте строк дії сертифіката, відповідність домену та підтримку сучасних версій TLS; не ігноруйте попередження браузера.

Перенаправлення переводить відвідувача із незахищеної HTTP-адреси на захищену HTTPS-версію того самого сайту. Якщо людина відкриє HTTP-посилання, а переходу на HTTPS немає, початковий запит може пройти незашифрованим. Сканер не встановлює, чи перехоплювали такі запити.

Рекомендується: Налаштуйте постійне перенаправлення всіх HTTP-адрес на відповідні HTTPS-адреси й перевірте, що воно не створює циклів.

HSTS повідомляє браузеру, що надалі з цим доменом слід з’єднуватися лише через HTTPS. Без цього правила браузер не має такої підказки від сайту. Це може залишити можливість незахищеного першого переходу з HTTP, але не доводить, що хтось його перехопив.

Рекомендується: Спершу переконайтеся, що HTTPS працює на всіх потрібних сторінках, а потім налаштуйте HSTS із поступовим збільшенням строку дії.

CSP задає браузеру правила, з яких джерел сторінка може завантажувати скрипти та інші ресурси. Без CSP браузер не має цього додаткового обмеження. Якщо на сторінку потрапить сторонній скрипт через окрему помилку, політика могла б зменшити його можливості; її відсутність не доводить, що такий скрипт є.

Рекомендується: Створіть політику дозволених джерел для скриптів та інших ресурсів і перевірте її на тестовій версії, щоб не порушити роботу сайту.

X-Frame-Options або правило frame-ancestors у CSP обмежують показ сторінки всередині чужого фрейму. Без такого обмеження зловмисний сайт може спробувати непомітно розмістити сторінку у фреймі й підштовхнути відвідувача до небажаного натискання. Перевірка не показує, що таке вже відбувається.

Рекомендується: Якщо вбудовування не потрібне, задайте X-Frame-Options SAMEORIGIN або CSP frame-ancestors із дозволеними джерелами.

Значення nosniff просить браузер не вгадувати тип вмісту файлу замість того, щоб покладатися на вказаний сервером тип. Без цього правила браузер може інтерпретувати окремі ресурси не так, як очікує сайт. Сам факт відсутності заголовка не означає, що файл уже виконався як код.

Рекомендується: Додайте заголовок X-Content-Type-Options: nosniff і переконайтеся, що сервер правильно вказує Content-Type для кожного ресурсу.

Ця політика визначає, яку частину адреси сторінки браузер передає іншому сайту під час переходу за посиланням або завантаження ресурсу. Надто відкрита або відсутня політика може передати зовнішньому сайту більше деталей URL, ніж потрібно, зокрема шлях чи параметри. Сканер не знає, чи містить конкретна адреса чутливі дані.

Рекомендується: Задайте обережну політику, наприклад strict-origin-when-cross-origin, і не розміщуйте секрети чи особисті дані в URL.

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

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

CORS визначає, яким стороннім сайтам браузер дозволяє читати відповіді цього домену. Дозвіл для всіх джерел може відкрити читання відповіді будь-якому сайту, якщо ресурс призначений для браузерного доступу. Сам заголовок не доводить, що там є приватні дані чи що вони доступні без входу.

Рекомендується: Перевірте, чи потрібен доступ із браузера стороннім доменам; замість * перелічіть лише довірені джерела та перевірте API окремо.

Secure обмежує передавання cookie захищеним HTTPS, а HttpOnly забороняє читати cookie зі скриптів сторінки. Якщо сесійна cookie не має цих атрибутів, її захист слабший у відповідних сценаріях. Головна сторінка може не встановлювати сесійних cookie, тому цей результат не описує всі сторінки після входу.

Рекомендується: Перевірте cookie авторизації та сесії на сторінках входу: використовуйте Secure, HttpOnly і доречне значення SameSite.

HTTP-заголовок Server може повідомляти тип або версію програмного забезпечення вебсервера. Така інформація іноді допомагає точніше обирати цілі для атак, якщо програмне забезпечення застаріле. Саме розкриття назви не є доказом уразливості.

Рекомендується: Приберіть зайві версії з публічних заголовків і регулярно оновлюйте серверне програмне забезпечення.

Файл security.txt публікує спосіб зв’язку для повідомлень про знайдені проблеми безпеки. Без нього досліднику може бути складніше знайти офіційний канал повідомлення. Відсутність файлу не означає, що сайт має уразливість.

Рекомендується: Опублікуйте актуальний security.txt за адресою /.well-known/security.txt із реальною контактною адресою та правилами повідомлення.

SPF-запис перелічує поштові сервери, яким дозволено надсилати листи від імені домену. Без SPF одержувачам складніше відрізнити дозволений сервер від стороннього, що намагається підробити адресу відправника. SPF не гарантує доставку й сам не зупиняє всі види підміни.

Рекомендується: Опублікуйте один коректний SPF-запис із фактичними поштовими сервісами та перевірте, щоб він не перевищував ліміти DNS-пошуку.

DMARC задає поштовим системам політику для листів, які не проходять перевірки домену, і може надсилати звіти власнику. Без DMARC власник не публікує цю політику для одержувачів. Це ускладнює контроль підміни домену в листах, але саме собою не доводить, що підроблені листи вже розсилали.

Рекомендується: Налаштуйте DMARC зі звітами, перевірте SPF і DKIM, а політику посилюйте поступово після аналізу легітимної пошти.

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

Рекомендується: Переконайтеся, що наявність або відсутність MX відповідає задуму; якщо пошта потрібна, звірте записи з налаштуваннями вашого поштового провайдера.

CAA дає власнику домену змогу визначити, які центри сертифікації можуть видавати для нього TLS-сертифікати. Без CAA немає цього додаткового обмеження для центрів сертифікації. Це не означає, що хтось уже отримав сторонній сертифікат або перехопив домен.

Рекомендується: Якщо ви керуєте видачею сертифікатів, додайте CAA для фактичного центру сертифікації й перевірте DNS перед наступним випуском.

Вік домену береться з доступних реєстраційних даних і показує, як давно його зареєстрували. Дуже молодий домен може бути приводом уважніше перевірити продавця, але сам вік не доводить шахрайство. Старий домен також не гарантує надійність.

Рекомендується: Звірте контакти, умови оплати й повернення та шукайте незалежні відгуки; не ухвалюйте рішення лише за віком домену.