HTTP - это прикладной протокол, по которому клиент и сервер обмениваются запросами и ответами. Когда браузер открывает страницу, мобильное приложение получает данные профиля или frontend отправляет форму на backend, очень часто в основе этого общения лежит именно HTTP.
HTTPS - это не отдельная логика приложения и не "другой интернет". Это тот же HTTP, но поверх защищённого соединения через TLS. Проще говоря, HTTP отвечает за смысл запроса и ответа, а HTTPS добавляет защиту канала: шифрование, проверку подлинности сервера и защиту от подмены данных по пути.
Для QA это одна из ключевых тем. Если не понимать разницу между HTTP и HTTPS, сложно уверенно разбирать сетевые проблемы, авторизацию, редиректы, работу cookie, безопасность формы логина и поведение приложения в браузере.
Как это работает
Когда клиент обращается к серверу по HTTP, он отправляет запрос. В запросе есть несколько важных частей:
- →метод, например GET, POST, PUT, DELETE
- →адрес ресурса
- →заголовки
- →иногда тело запроса
Сервер принимает запрос, обрабатывает его и возвращает ответ со статус-кодом, заголовками и телом ответа.
Важно понимать, что HTTP сам по себе stateless, то есть не хранит состояние между запросами. Сервер не "помнит" клиента только потому, что тот сделал предыдущий запрос. Состояние обычно поддерживается через cookie, токены, сессии или данные на стороне приложения.
HTTPS работает почти так же с точки зрения QA, но перед передачей HTTP-данных сначала устанавливается защищённое TLS-соединение. Во время этого шага клиент проверяет сертификат сервера и договаривается о защищённом канале. Только после этого начинают передаваться сами HTTP-запросы и ответы.
- →HTTP - правила общения клиент-сервер
- →HTTPS - HTTP + TLS-защита канала
Что именно меняется при HTTPS
Есть три практических свойства, которые QA должен понимать.
Первое - конфиденциальность. Данные по пути не должны читаться посторонними как обычный открытый текст. Это особенно важно для логина, паролей, токенов, платёжных данных и персональной информации.
Второе - целостность. Данные не должны незаметно измениться по дороге от клиента к серверу или обратно.
Третье - аутентификация сервера. Клиент должен убедиться, что он действительно общается с нужным сервером, а не с подменённой точкой.
Но важно не переоценивать HTTPS. Он не делает систему автоматически безопасной. Если backend отдаёт лишние данные, плохо настроены права, есть уязвимость в бизнес-логике или insecure direct object reference, HTTPS это не исправит. Он защищает канал, а не сам продукт целиком.
Что важно QA
Для тестировщика HTTP и HTTPS - это не просто теория про сеть. Это рабочий инструмент диагностики.
Когда ты открываешь DevTools, Charles, Proxyman, Postman или логи gateway, ты по сути смотришь на HTTP-уровень. Поэтому QA должен уметь читать хотя бы базовую картину:
- →какой запрос ушёл
- →на какой URL
- →с каким методом
- →с какими headers
- →что было в body
- →какой статус вернулся
- →что пришло в ответе
- →был ли редирект
- →не сломалась ли авторизация
- →нет ли проблем именно на уровне HTTPS
Особенно полезно понимать, что ошибка может быть в разных местах.
Например, пользователь видит "Не удалось войти". Причины могут быть разными: сервер вернул 401, frontend неправильно обработал 200, запрос ушёл по HTTP вместо HTTPS, cookie не сохранилась, потому что не выставлен Secure, сертификат или прокси на тестовом стенде настроен неверно, произошёл redirect loop между http и https. Снаружи всё выглядит как одна ошибка входа, но на деле точки отказа разные.
На что смотреть в проверках
- →есть ли принудительный переход с http на https
- →открывается ли сайт без предупреждений браузера о сертификате
- →нет ли mixed content, когда HTTPS-страница тянет небезопасные ресурсы по HTTP
- →выставлены ли чувствительные cookie с флагами Secure и, где нужно, HttpOnly
- →не утекают ли токены и чувствительные данные в URL, логи или редиректы
- →одинаково ли работает нужный сценарий за reverse proxy, CDN и на тестовых стендах
- →не ломаются ли вызовы API из-за CORS, прокси или сертификатов
Для API QA ещё важно помнить: сам по себе ответ 200 OK не говорит, что всё хорошо с безопасностью или транспортом. И наоборот, проблема соединения не всегда означает ошибку бизнес-логики.
Практический пример
Представь форму логина. Пользователь вводит email и пароль, браузер отправляет POST на endpoint авторизации, сервер проверяет данные и возвращает токен или session cookie.
Что здесь важно QA:
- →форма действительно отправляет запрос на HTTPS endpoint
- →пароль не уходит в query string
- →после логина сессия или cookie выставляется корректно
- →cookie имеет нужные security flags
- →если пользователь открыл старую http ссылку, его корректно переводит на https
- →после редиректа авторизация не ломается
- →браузер не показывает certificate warning
Что должен вынести QA из этой темы
- →HTTP отвечает за формат и смысл обмена запросами и ответами.
- →HTTPS - это HTTP поверх TLS, то есть защищённый канал связи.
- →HTTPS нужен для шифрования, целостности данных и проверки сервера.
- →HTTPS не заменяет проверку бизнес-логики, прав доступа и безопасности приложения.
- →Для расследования дефектов QA должен видеть не только экран, но и сетевой слой.
Что ещё почитать
- →Внутри базы: Методы, статус-коды, заголовки
- →Внутри базы: Аутентификация и авторизация
- →Внешний материал: MDN HTTPS