CORS и безопасность

Origin — это схема плюс хост плюс порт: http://localhost:5173 и http://localhost:8080 — разные origin-а, хотя разница в одном числе. Same-origin policy — правило браузера: скрипт страницы может свободно читать ответы только своего origin-а; ответ чужого origin-а он получает, но не имеет права увидеть. Отсюда классическая сцена: фронтенд на 5173 зовёт fetch("http://localhost:8080/api/v1/todos") и в консоли всплывает «blocked by CORS policy», хотя curl и Postman тот же адрес отвечают без проблем — браузер там не участвует, а CORS — это правило именно браузера. Важно понять, что CORS — не запрет на отправку, а запрет на чтение. Запрос браузер выполнит и даже получит ответ — сервер отработает, база изменится, — но JS-код ответа не увидит, пока сервер сам не разрешит: заголовком Access-Control-Allow-Origin с именем origin-а клиента. Это принципиально меняет представление о защите: CORS не закрывает API от чужих клиентов — curl-то работает, — он лишь регулирует, какие веб-страницы вправе читать ответы. Защита самого API — токены из прошлого урока и звенья; CORS — про дружбу с честным фронтендом. Серверная часть темы — пакет github.com/gin-contrib/cors: go get github.com/gin-contrib/cors, cors.New(cors.Config{...}) — одно звено на r.Use, и дальше вся работа происходит в заголовках ответа. Связку gin cors надо настроить один раз и понимать построчно, потому что ломается она в самых неожиданных местах: то preflight не видит Authorization, то AllowCredentials конфликтует со звёздочкой, то CDN кэширует ответ одного origin-а для всех. Разберём всё по порядку: сначала механика простых и preflight-запросов, потом конфиг, потом безопасность за пределами CORS.

Браузер делит cross-origin запросы на два класса. Simple-запросы — GET, HEAD и POST с Content-Type из тройки text/plain, application/x-www-form-urlencoded и multipart/form-data, без авторских заголовков — браузер отправляет сразу, прикладывая заголовок Origin; сервер в ответе либо ставит Access-Control-Allow-Origin, и JS прочитает ответ, либо молчит, и браузер скрывает ответ, хотя обработка состоялась. Multipart из урока про загрузку файлов попадает в simple-класс именно из-за этого списка. Всё остальное — POST с Content-Type: application/json, PUT, DELETE, PATCH, любой запрос с Authorization или X-* заголовками — требует preflight: перед настоящим запросом браузер шлёт OPTIONS с заголовками Origin, Access-Control-Request-Method (что собирается сделать) и Access-Control-Request-Headers (какие заголовки хочет поставить). Сервер обязан ответить 204 без тела и перечислить разрешения: Access-Control-Allow-Origin — конкретный origin клиента, Access-Control-Allow-Methods — список методов, Access-Control-Allow-Headers — список заголовков, Access-Control-Max-Age — сколько секунд браузеру можно не спрашивать снова. Только после удачного preflight уходит настоящий запрос — и CORS-заголовки должны быть и на нём, иначе ответ всё равно скрыт. Два заголовка, о которых забывают. Access-Control-Expose-Headers: сервер по умолчанию показывает JS-у только Cache-Control, Content-Language, Content-Type, Expires, Last-Modified и Pragma — ваш X-Total-Count для пагинации JS не увидит, пока вы его не откроете. Access-Control-Allow-Credentials: true — разрешает браузеру прикладывать cookie и Authorization к cross-origin запросу; без него fetch с credentials: "include" получит cookie, но ответ будет скрыт. И Vary: Origin — когда заголовок зависит от присланного Origin, кэши обязаны знать, что нельзя отдавать всем ответ, собранный для одного origin-а; gin-contrib/cors ставит его сам, но понимать причину нужно до первого кэширующего прокси.

Белый список AllowOrigins — рабочая норма: перечислите origin-а целиком, со схемой и портом, без завершающего слэша — http://localhost:5173, https://goma.dev; сравнение строковое, и «почти тот же origin» не пройдёт. Для публичного API без cookie и Authorization существует AllowAllOrigins: true — сервер отвечает Access-Control-Allow-Origin: и разрешает чтение всем; для открытых справочников погоды и курсов — честный выбор, для всего с аутентификацией — нет: браузер отклоняет сочетание «» с credentials — если Access-Control-Allow-Credentials: true, звёздочка в Allow-Origin игнорируется, и ответ скрыт; cookie-сессии из урока про cookie требуют точного origin-а в заголовке. Промежуточные случаи решают два инструмента. AllowOriginPatterns — список масок вида "https://*.goma.dev": поддомены продукта без ручного списка; звёздочка внутри маски работает на сегмент хоста, схемы и порты маска тоже учитывает. AllowOriginFunc — функция func(origin string) bool: верните true, чтобы разрешить; внутри — любые проверки, от regex до похода в таблицу арендаторов: для мультитенантных систем, где каждому клиенту выдан свой поддомен, это единственный путь. При динамических разрешениях правило кэширования из урока про статику приобретает зубы: разным origin-ам уходят разные заголовки, поэтому Vary: Origin обязателен (включайте его и сами, если рисуете заголовки руками), иначе CDN с радостью закэширует ответ для goma.dev и раздаст его тестовому стенду. И гигиена: не отражайте присланный Origin без проверки — «верну тебе твой Origin, что бы это ни было» эквивалентно звёздочке, только с притворством безопасности. Наконец, валидация конфига: cors.New прогоняет Config через Validate и паникует на противоречиях при старте — не настроили ни одного источника разрешений, сервер не поднимется; это раздражает один раз на деве и спасает прод, где нет CORS без списков.

CORS-звено гибко в масштабе, и от места вешания зависит, кто получит заголовки. r.Use(cors.New(...)) на движке — все маршруты, включая группы /api/v1 из урока про роуты и HTML-страницы из урока про шаблоны; для монолита с одним origin-ом фронтенда это нормально, но страницы CORS не нужны, и звено честно молчит для same-origin запросов: без заголовка Origin в запросе cors не ставит ничего. На группе — api := r.Group("/api/v1"); api.Use(cors.New(...)) — заголовки получит только API, а статика из урока 11 и HTML останутся без лишних заголовков; для нескольких фронтендов с разными правами собирают по звену на группу — админке один AllowOrigins, публичному API другой, и конфиги не пересекаются. Два правила порядка. Первое: cors выше Auth — preflight-запрос OPTIONS не несёт Authorization, и если гвард из урока про JWT стоит раньше, он оборвёт OPTIONS с 401 ещё до CORS-ответа; браузер покажет «preflight failed», а вы будете искать проблему в конфиге, который ни при чём. Второе: одно звено на маршрут — двойной r.Use(cors.New(...)) на движке и на группе даст два Access-Control-Allow-Origin в одном ответе, и браузер отклонит ответ как некорректный: дубликаты CORS-заголовков запрещены. Дальше — взаимодействие с другими звеньями: limitBody из урока про загрузку файлов на OPTIONS не мешает (тело пустое), но звено логирования из урока про recovery теперь пишет в лог и preflight-ы — при желании фильтруйте их, чтобы логи не распухали. И про 404: если cors висит на движке через r.Use, он работает и на несуществующих маршрутах — браузер увидит аккуратный 404 вместо «блокировки»; если звено на группе, промах мимо группы получит ответ без CORS-заголовков, и отладка будет странной. Универсальный совет: держите cors на самом верхнем уровне, где нужен, и проверяйте порядок звеньев до того, как фронтенд начнёт жаловаться.

CORS закрывает один вопрос — чтение cross-origin ответов, — но безопасность gin шире: браузер уважает ещё десяток заголовков, и большинство из них ставится одним звеном, механика которого — урок про кастомные middleware: c.Writer.Header().Set до c.Next(). Strict-Transport-Security: max-age=63072000; includeSubDomains — HSTS: получив его по HTTPS, браузер на два года забывает про http для этого домена и переводит все запросы на https сам; ставьте только там, где HTTPS уже факт, — на http-деве заголовок бессмыслен и только путает. X-Content-Type-Options: nosniff — запрет MIME-sniffing: без него браузер угадывает тип по содержимому и может «починить» text/plain до исполняемого HTML; с nosniff он уважает Content-Type и отвергает стили и скрипты с чужим типом. Связка с загрузками из урока про файлы прямая: пользовательский файл, отдающийся как text/html, — это хранимый XSS, и nosniff — второй рубеж после http.DetectContentType. X-Frame-Options: DENY (или SAMEORIGIN) — запрет встраивания в iframe, против clickjacking: страница-приманка поверх вашего сайта не соберётся. Content-Security-Policy — whitelist источников: default-src 'self' разрешает грузить скрипты, стили и картинки только со своего origin-а, инлайновые скрипты и внешние CDN молча блокируются; CSP — самый мощный противовес XSS после экранирования из урока про шаблоны, но и самый капризный — начинайте с report-only режима и ужесточайте по логам. Referrer-Policy: strict-origin-when-cross-origin — наружу уходит только origin, а не полный URL с токенами в query. И гигиена сигнатур: net/http подписывает ответы «Server: gin» — звену по силам Header().Del("Server"), чтобы не публиковать фреймворк и версию собирающим статистику сканерам. Это не чек-лист «поставь всё», а меню: выберите, что ваш продукт должен запретить, и вынесите в одно звено рядом с cors — две строки на r.Use, вся безопасность заголовков в одном месте.

CSRF — cross-site request forgery — атака, при которой страница злоумышленника отправляет запрос на ваш API от имени залогиненного пользователя, и браузер сам прикладывает cookie. Механика: вы залогинены в трекер, сессионная cookie живёт; в соседней вкладке открыт bad-site.example, который содержим форму <form action="http://localhost:8080/api/v1/todos" method="POST"> и скрипт, её отправляющий; браузер выполняет cross-site POST на ваш сервер и — если SameSite позволяет — прикладывает вашу cookie; сервер видит «свой» пользовательский cookie и создаёт задачу. Обратите внимание: CORS тут бессилен, и это самый частый misconception темы — CORS ограничивает чтение ответа браузером, но не отправку запроса; bad-site и не хотел читать ответ, ему хватило самого факта «сервер выполнил действие». Первая линия обороны уже стоит: SameSite из урока про cookie. Lax — дефолт современных браузеров — пропускает cross-site cookie только в переходах верхнего уровня по GET; форма POST с чужого сайта cookie не получит, и CSRF через форму умирает; Strict — отрезает и переходы; None — оставляет дыру и обязывает к следующей линии. Вторая линия — CSRF-токен: сервер при выдаче формы кладёт в сессию псевдослучайное значение и рисует его скрытым полем; обработчик сверяет пришедшее поле с сессией — чужой сайт значение не знает и подделать не может; пакет gorilla/csrf умеет это из коробки вместе с HMAC-защитой cookie-токена. Третья — проверка Origin/Referer в звене: если Origin есть и он не в белом списке — 403. JWT из прошлого урока сам по себе CSRF-устойчив: Authorization-заголовок браузер никуда не прикладывает автоматически — атака требует, чтобы JS жертвы сам положил токен, а на чужой странице он недоступен. Поэтому связка «JWT в заголовке для API, сессии с SameSite для SSR» — не только удобство, но и безопасность: у каждой схемы свой фронт. Это обзор — полный разбор с формами и токенами заслуживает отдельного урока, а сегодня зафиксируйте главное: SameSite по умолчанию, CSRF-токен на state-changing формах, и не путайте CORS с защитой от CSRF.

CORS-проблемы решаются curl-ом за минуты, потому что preflight — обычный HTTP-запрос: curl -i -X OPTIONS http://localhost:8080/api/v1/todos -H "Origin: http://localhost:5173" -H "Access-Control-Request-Method: POST" -H "Access-Control-Request-Headers: Content-Type,Authorization" — и вы смотрите на ответ как на обычный: 204 и четыре заголовка означают «preflight пройдёт», 401 говорит «поймал Auth-гвард — поднимите cors выше звеньев», 404 — звено не на том уровне, а молчаливое 204 без Access-Control-Allow-Origin — origin не в списке или конфиг не применился. Дальше настоящий запрос: curl -i -X POST http://localhost:8080/api/v1/todos -H "Origin: http://localhost:5173" -H "Content-Type: application/json" -d '{"title":"тест"}' — в ответе должен быть Access-Control-Allow-Origin, иначе JS ответ не увидит, даже если всё остальное идеально. Четыре частые грабли. Origin обязан совпасть до символа: схема, хост и порт, без завершающего слэша; http://localhost и http://localhost:5173 — разные origin-ы, и порт в http обязателен. Забытый AllowHeaders: Content-Type прислали, в списке его нет — preflight вернётся с пустым Allow-Headers, и браузер откажется слать настоящий запрос; сообщение в консоли при этом жалуется на заголовок, а не на конфиг. Дубликат звена: cors на движке и на группе — два Access-Control-Allow-Origin, браузер отбраковывает ответ. Пятиминутный кэш: правите конфиг, проверяете — а браузер всё ещё держит старый preflight из кэша Max-Age; в DevTools поставьте галку Disable cache или откройте инкогнито. И финальный аккорд: браузерная консоль при CORS-ошибке пишет причину прямо в тексте — «No 'Access-Control-Allow-Origin' header is present», «Response to preflight request... status 401» — читайте её до того, как лезть в код.