Когда начинаешь тестировать веб-приложения, довольно быстро привыкаешь смотреть на HTTP-запросы: метод, URL, статус-код, body, headers. Но есть вещи, которые сначала вообще не замечаешь. Для меня одной из таких вещей оказался заголовок Origin и связанный с ним механизм CORS.

Для начала, что вообще такое origin? Если сильно упростить, origin определяется тремя вещами: протокол + домен + порт. Например: https://example.com:443 Если хотя бы одна из этих частей отличается, это уже другой origin.

Теперь представим ситуацию. Пользователь заходит на обычный сайт, а на странице выполняется JavaScript-код. Этот код может отправлять HTTP-запросы к другим ресурсам. И здесь возникает вопрос: а что, если разрешить любому сайту свободно читать ответы от других сайтов?

Представим, что пользователь уже авторизован в каком-нибудь интернет-банке, почте или другом сервисе. Он открывает совершенно обычную страницу, на которой находится вредоносный JavaScript. Сам пользователь может вообще ничего не заметить. Скрипт в фоне может попытаться обратиться к другому сайту в контексте этого пользователя. Если бы браузер позволял такому скрипту свободно читать ответы другого сайта, это могло бы стать серьёзной проблемой: злоумышленник потенциально получил бы доступ к данным, которые пользователь уже имеет право видеть. Именно поэтому в браузере существует Same-Origin Policy — политика безопасности, которая ограничивает взаимодействие JavaScript-кода с ресурсами другого origin. А CORS позволяет серверу явно сказать браузеру: «Для такого origin доступ к моему ответу разрешён».

И здесь есть важный момент, который я сам не сразу понял: CORS не означает, что сервер обязательно отклоняет сам HTTP-запрос. Сервер может получить запрос, обработать его и вернуть 200 OK. Но браузер проверяет CORS-заголовки ответа. Если политика не разрешает текущему origin получить этот ответ, браузер не отдаёт ответ JavaScript-коду страницы.Поэтому можно получить на первый взгляд странную ситуацию: запрос ушёл → сервер ответил 200 OK → а JavaScript не может прочитать ответ.

И вот здесь Origin становится особенно интересен для QA. По этому заголовку можно увидеть, с какого origin инициируется cross-origin запрос, а дальше уже проверять, как приложение и сервер должны обрабатывать такие обращения. Мне кажется, это одна из тех вещей, которые полезно понимать не только разработчику, но и тестировщику, особенно при работе с веб-приложениями и API.

А какие HTTP-механизмы или заголовки вы сами для себя открыли не сразу, хотя потом поняли, что они реально полезны в работе? 👇