Перейти на PRO

Какие существуют способы передачи токена аутентификации в HTTP-запросе?

Тип вопроса: API тестирование Вероятность: 10% Категория: QA Тестировщик

Ответ

Токен доступа обычно передается в HTTP-запросе одним из следующих способов, каждый из которых имеет свои особенности применения и уровень безопасности.

1. В заголовке Authorization (Наиболее распространенный и рекомендуемый способ) Чаще всего используется схема Bearer.

GET /api/user/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

2. В cookie (Для веб-приложений) Сервер устанавливает токен в cookie, который браузер автоматически отправляет с каждым запросом.

GET /dashboard HTTP/1.1
Host: example.com
Cookie: session_token=abc123def456; HttpOnly; Secure
  • Плюсы: Удобство для браузерных SPA.
  • Минусы: Риск CSRF-атак (требует дополнительных мер).

3. В теле запроса (Body) Используется реже, обычно для специфичных потоков (например, OAuth 2.0).

{
  "grant_type": "refresh_token",
  "refresh_token": "abc123...",
  "client_id": "your_client_id"
}

4. В параметре URL (Query Parameter) — НЕ РЕКОМЕНДУЕТСЯ

GET /api/data?access_token=abc123 HTTP/1.1
  • Критический недостаток: Токен остается в логах сервера, истории браузера и реферерах, что представляет угрозу безопасности.

Best Practice: Для API предпочтительно использовать заголовок Authorization: Bearer <token>. Для веб-приложений, работающих в браузере, часто применяется комбинация HttpOnly/Secure cookies для хранения токена и CSRF-токенов для защиты.

Ответ 18+ 🔞

А, ну это ж классика, блядь! Токен, сука, как ключ от квартиры, где деньги лежат. И его, этого пидораса, можно в разные щели сунуть, но не все щели одинаково полезны, ёпта. Сейчас разберём, кто куда и зачем.

1. В заголовке Authorization (Это как паспорт предъявить — нормально, официально) Тут всё чинно-благородно, чаще всего с приставкой Bearer. Типа «носитель, предъявитель». Сервер смотрит в заголовок и говорит: «А, ну ладно, проходи».

GET /api/user/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Работает, проверено. Для API — самое оно.

2. В куках (Для веб-приложений, где браузер — главный распиздяй) Сервер такой: «На, мудила, держи печеньку!» И ты её жуёшь с каждым запросом.

GET /dashboard HTTP/1.1
Host: example.com
Cookie: session_token=abc123def456; HttpOnly; Secure
  • Плюсы: Удобно, браузер сам всё таскает, не надо мозги парить.
  • Минусы: Но тут, сука, подкрадывается CSRF-атака — какой-то ушлёпок с другого сайта может заставить твой браузер отправить эту куку куда не надо. Так что без дополнительных пиздюлей (типа CSRF-токенов) — пипец.

3. В теле запроса (Body) — для особых, извращённых случаев Типа OAuth 2.0, когда ты уже такой весь из себя «дайте мне, блядь, новый токен, старый проёбан». Толкаешь его прямо в JSON, как есть.

{
  "grant_type": "refresh_token",
  "refresh_token": "abc123...",
  "client_id": "your_client_id"
}

Редко, но метко.

4. В параметре URL (Query Parameter) — А ЭТО ВООБЩЕ, БЛЯДЬ, НЕ ДЕЛАЙ ТАК!

GET /api/data?access_token=abc123 HTTP/1.1

Вот это, сука, верх идиотизма! Твой токен теперь:

  1. В логах сервера — «Привет, я тут!»
  2. В истории браузера — «Посмотри на меня!»
  3. В реферерах, если куда-то ушёл — «Ловите меня, я весь тут!» Это как оставить ключи от хаты под ковриком с надписью «КЛЮЧИ ТУТ». Пиздец безопасности, в рот меня чих-пых!

Итог, ёбаный в рот: Для своих API — только заголовок Authorization: Bearer <token>, без вариантов. Для веб-приложений в браузере — куки, но обязательно HttpOnly и Secure, и сверху ещё CSRF-токеном припорошить, чтобы не обосраться. А в URL его пихать — это диагноз, иди лечись.

© ХакСобесов, 2026
support@hacksobesov.com