Главное по разделу
HTTPS и TLS
HTTPS защищает канал между браузером и сервером. Передаваемые данные идут через зашифрованное TLS-соединение, поэтому логин и содержимое форм не должны передаваться открытым HTTP-трафиком.
HSTS
Strict-Transport-Security сообщает браузеру, что домен следует открывать только по HTTPS. Это уменьшает риск случайного отката на незащищённый HTTP после первого безопасного посещения.
HTTP security headers
На шаблоне предусмотрены X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-Frame-Options, Cross-Origin-Opener-Policy и Content-Security-Policy.
Cookies и сессии
Сессионные cookies в административной части используют HttpOnly и SameSite; при HTTPS добавляется Secure.
KYC и AML
Проверки личности и финансовых операций применяются отдельно от транспортного шифрования. Они помогают подтвердить владельца аккаунта и выполнять правила платформы.
HTTPS и TLS: что именно они защищают
HTTPS — это HTTP поверх защищённого TLS-соединения. Оно шифрует передачу данных между браузером и сервером, помогает обнаруживать подмену трафика и подтверждает сертификат для домена. На практике пользователь должен видеть HTTPS до ввода пароля или платёжных данных.
HSTS и защитные HTTP-заголовки
HSTS сообщает совместимому браузеру, что домен следует открывать только через HTTPS. На стороне приложения также настроены Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy и Cross-Origin-Resource-Policy. Эти механизмы решают разные задачи: ограничивают источники скриптов, запрещают MIME-sniffing, уменьшают утечки referrer и сужают доступ к чувствительным API браузера.
Безопасность сессии и административной части
Административная панель закрыта от индексации, сессия использует HttpOnly, SameSite=Strict и Secure при HTTPS, а формы защищены CSRF-токеном. Служебные каталоги конфигурации, контента и storage не должны быть доступны напрямую из публичного веб-пространства.
Что техническая защита не может сделать за пользователя
Даже сильная конфигурация сервера не спасает от передачи пароля фишинговому сайту. Поэтому мы соединяем технические меры с понятной навигацией: основной домен опубликован открыто, контакты поддержки вынесены отдельно, а ссылки на зеркала и приложения проверяются через официальный сайт.
Технические меры защиты EZCASH
| Механизм | Что делает | Что проверяет пользователь |
|---|---|---|
| HTTPS + TLS | Шифрует трафик между браузером и сервером | HTTPS и домен |
| HSTS | Не допускает обычный HTTP после получения политики | Адрес открывается по HTTPS |
| Content-Security-Policy | Ограничивает источники активного контента | Работает на стороне браузера |
| X-Content-Type-Options | Запрещает MIME-sniffing | Технический заголовок |
| Referrer-Policy | Ограничивает передачу referrer | Технический заголовок |
| HttpOnly/SameSite cookies | Снижает риск кражи/межсайтовой отправки сессии | Не передавать cookie вручную |
Что открыть дальше
Переходите в профильный раздел, если вопрос уже вышел за рамки этой страницы.
Безопасный вход
Практика авторизации на официальном домене.
Открыть →Конфиденциальность
Как описывается обработка пользовательских данных.
Открыть →Лицензия и оператор
Проверяемые юридические данные.
Открыть →Частые вопросы
Есть HSTS?
Да, при работе сайта по HTTPS серверный шаблон отправляет Strict-Transport-Security.
Данные шифруются?
Соединение браузера с сайтом использует HTTPS/TLS.
