Веб-основы для тестировщика

Путь запроса и где он рвётся

Запрос проходит четыре понятных шага. Первый - DNS: имя api.example.com превращается в числовой адрес машины. Второй - TCP: между твоим клиентом и этой машиной устанавливается соединение. Третий - TLS: соединение шифруется, стороны сверяют сертификат. Четвёртый - собственно HTTP-запрос и ответ приложения.

Зачем тестировщику эта лестница: она даёт порядок диагностики. «Не работает» может означать «имя не резолвится», «соединение не устанавливается», «сертификат просрочен» и «приложение вернуло 500» - это четыре разные команды и четыре разных ответственных. Разбирают снизу вверх, и до кода доходят последним.

// Сам HTTP-запрос устроен просто: метод, путь, параметры после вопросительного знака, заголовки (служебные пары «имя: значение») и тело. Всё это видно во вкладке Network панели разработчика в браузере - там же видно, что ушло и что вернулось, вплоть до байта.

DNS

превращение имени сайта в числовой адрес машины

заголовки

служебные пары «имя: значение» рядом с запросом и ответом

CORS: замер в настоящем браузере

Вернусь к опыту из начала. Источник (origin) - это сочетание протокола, домена и порта. Страница с одного источника, сервис на другом - для браузера это чужой источник, даже если оба на твоей машине и различаются только портом.

CORS (cross-origin resource sharing) - правило браузера: прежде чем отдать странице ответ от чужого источника, он проверяет, разрешил ли тот сервис такое обращение специальным заголовком. Замер: сервис без заголовка - страница получила «Failed to fetch»; тот же сервис с заголовком разрешения - страница получила {"balance":105000}; тот же адрес запросом не из браузера - 200 и те же данные.

// Отсюда вывод, который экономит дни. Воспроизвести ошибку CORS через curl или Postman нельзя. Это программы, которые шлют запросы к серверу напрямую, без страницы: они не браузеры и правило источников не применяют. Поэтому фразу разработчика «у меня в Postman работает» нельзя принимать как аргумент - Postman тут ничего не проверяет. Разбирать надо в браузере, глядя на заголовки ответа и на предварительный запрос OPTIONS, который браузер шлёт перед непростыми обращениями.

источник (origin)

протокол плюс домен плюс порт; граница правил браузера

CORS

cross-origin resource sharing: правило браузера о доступе к чужому источнику

Куки и токены: что видно снаружи

Кука - маленькая пара «имя-значение», которую сервер просит браузер запомнить и присылать обратно. Замер: сервис поставил две куки - session с признаком HttpOnly и theme без него. Скрипт на странице, запросив список кук, увидел только theme=dark. Сессионная кука для него невидима - и ровно это спасает при XSS (cross-site scripting), когда на страницу попадает чужой скрипт: украсть сессию через него не выйдет.

Остальные признаки куки тоже проверяют: Secure (передаётся только по шифрованному соединению), SameSite (не отправлять её при переходах с чужих сайтов - защита от CSRF (cross-site request forgery), когда чужая страница дёргает твой сервис от твоего имени), срок жизни, домен и путь.

// Второй способ носить личность - токен в заголовке. Я собрал такой токен и разобрал его: середина читается обычным декодированием без всякого ключа - там оказалось {"sub":"user-42","role":"user","email":"anna@mail.ru"}. При этом подменить роль на admin не вышло: подпись перестала сходиться. Вывод точный - подделать нельзя, а прочитать может кто угодно, поэтому в JWT (JSON Web Token) не кладут ничего, что нельзя показывать.

HttpOnly

признак куки: скрипту страницы она не видна

JWT

JSON Web Token: подписанный токен; закодирован, но не зашифрован

Как отвечать: «Почему ошибка CORS видна только в браузере?»

Потому что это правило самого браузера, а не запрет сервера. Работает оно так: когда скрипт на странице одного источника просит данные у другого источника, браузер перед тем, как отдать странице ответ, проверяет, разрешил ли тот сервис такое обращение ответным заголовком. Если разрешения нет - браузер сам блокирует чтение и показывает ошибку, хотя сервер запрос вполне мог обработать. Я проверял ровно этот сценарий: страница получила «Failed to fetch», а тот же самый адрес, запрошенный не из браузера, вернул двести и полные данные. Отсюда практический вывод: воспроизвести CORS через curl или Postman невозможно, они не браузеры и правило источников не применяют, у них запрос проходит всегда. Поэтому разбирать надо в браузере: смотреть предварительный запрос OPTIONS и заголовки разрешения в ответе. И когда разработчик говорит «у меня в Postman всё работает» - это не аргумент, Postman в этом месте вообще ничего не проверяет.

Почему это сильный ответ: назван корень (правило браузера, не сервера), объяснён механизм, приведено наблюдение с двумя разными исходами и сделан практический вывод про инструменты.

На чём валят

• −Разбирать CORS через curl: правило накладывает браузер, консольный клиент его не применяет.
• −Класть личные данные в токен «он же закодирован» - середина читается без ключа.
• −Сессионная кука без HttpOnly: чужой скрипт на странице заберёт её вместе с сессией.
• −Проверять выход из аккаунта только по интерфейсу - токен может остаться живым на сервере.
• −Забыть про кэш: «починили, а у пользователя по-старому» - ответ приехал из сохранённой копии.