10.4Безопасность и защита сервиса

Разбери реальные уязвимости на границе сервиса: SQL injection, mass assignment, SSRF, IDOR, CSRF, XSS и CORS. Для каждой определи, кто контролирует вход, какой слой обязан его проверять и чем именно исправляется конкретный дефект.

Одна мысль, из которой выводится вся глава

Почти каждая уязвимость из этого списка сводится к стёртой границе между данными и кодом или к доверию к тому, что контролирует не сервер. В SQL-инъекции пользовательская строка стала куском SQL, в XSS стала куском HTML, в SSRF превратилась в адрес, куда сервер сам пошёл. Остальное про доверие. При CSRF сервер поверил, что раз кука пришла, значит запрос осознанный. При IDOR он поверил идентификатору из URL, при mass assignment поверил набору полей во входном JSON. Если держать в голове эту рамку, ответы перестают быть списком заклинаний.

SQL-инъекция

Классика, которую всё ещё находят в проде - обычно не в основном CRUD, а в отчётах, поиске, админке и там, где «плейсхолдер не подставляется»: сортировка, имя таблицы, IN (...) с динамическим числом элементов. Механика всегда одна: строка пользователя попадает в текст запроса, СУБД разбирает этот текст целиком и не может отличить, какая часть была задумана как данные.

// Уязвимо. Такое и находят на пентестах.
func (r *Repo) UserByID(ctx context.Context, raw string) (*User, error) {
    q := "SELECT id, email, is_admin FROM users WHERE id = " + raw
    row := r.db.QueryRowContext(ctx, q)
    ...
}

При raw = "1" всё работает, тесты зелёные. При raw = "1 OR 1=1 --" получается WHERE id = 1 OR 1=1 --: условие тождественно истинно, а -- отрезает всё, что шло следом. Дальше атака развивается по накатанной:

• Расширение выборки. С OR 1=1 вываливается вся таблица.
• UNION-инъекция подставляет в ту же форму ответа чужие колонки: 1 UNION SELECT id, password_hash, NULL FROM users (типы колонок должны сойтись, отсюда NULL на месте is_admin).
• Blind / boolean-based. Ответа не видно, зато видно, изменился ли он: 1 AND (SELECT substr(password_hash,1,1) FROM users WHERE id=1)='a', и хеш вытаскивается посимвольно.
• Time-based обходится без ответа вовсе, ему хватает времени: 1 AND (SELECT 1 FROM pg_sleep(5)) = 1. Работает даже там, где ответ всегда 200 и пустой.
• Stacked queries проходят, если драйвер разрешает несколько операторов в одном сообщении: 1; DROP TABLE users; --. В PostgreSQL расширенный протокол такое запрещает, а Exec с простым протоколом или MySQL с multiStatements=true пропустят спокойно.

Почему параметризация работает, а экранирование - нет

Плейсхолдер не «умный escape». В расширенном протоколе PostgreSQL клиент шлёт два разных сообщения: Parse с текстом запроса и Bind со значениями. Когда сервер видит значение, синтаксическое дерево уже построено, и оно ляжет в конкретный лист этого дерева. Никакая строка не «дорастёт» до нового предиката: грамматика уже разобрана. Поэтому параметризация риск не смягчает, а устраняет.

Ручное экранирование решает ту же задачу с другого конца - пытается угадать, что именно опасно. И проигрывает сразу по нескольким причинам:

• Правила зависят от диалекта и настроек. В MySQL при NO_BACKSLASH_ESCAPES обратный слеш перестаёт экранировать; в PostgreSQL поведение E'...' и standard_conforming_strings различается. Функция, написанная под одну конфигурацию, дырявая в другой.
• Кодировки. Классическая атака на GBK/SJIS: байт 0x5C оказывается второй половиной многобайтового символа, и добавленный слеш «съедается», освобождая кавычку. Экранирование, не знающее charset соединения, ломается.
• Числовой контекст. Экранируют кавычки, но если значение подставляется без них (WHERE id = 1 OR 1=1), атакующему кавычки и не нужны.
• Это ручная работа. Хватит одного забытого места - и всё остальное экранирование теряет смысл. Параметризация ошибается «в безопасную сторону»: забыл плейсхолдер, и запрос обычно просто не компилируется или падает на несовпадении числа аргументов.

ORDER BY и имена таблиц - куда плейсхолдер не ставится

Плейсхолдер подставляет значение. А имя колонки, направление сортировки, имя таблицы или схемы относятся к идентификаторам, к грамматике запроса, и параметр на их месте не сработает: имя таблицы СУБД не примет, а ORDER BY $1 молча отсортирует по константе, то есть никак. LIMIT $1 и OFFSET $2, наоборот, обычные значения. В зрелых проектах реальные инъекции чаще всего находят именно тут: везде параметризовано, а сортировка склеена. Рабочее решение одно: маппинг из белого списка. Клиент присылает ключ, а сервер превращает его в заранее написанный фрагмент SQL.

// Клиент присылает sort=created_at&order=desc, но в SQL уезжает только то,
// что мы написали сами. Строки пользователя в тексте запроса нет.
var sortable = map[string]string{
    "created_at": "p.created_at",
    "title":      "p.title",
    "views":      "p.views_count",
}

func orderClause(q url.Values) (string, error) {
    col, ok := sortable[q.Get("sort")]
    if !ok {
        if q.Get("sort") == "" {
            return "p.created_at DESC, p.id DESC", nil // детерминированный дефолт
        }
        return "", fmt.Errorf("%w: неизвестное поле сортировки", ErrValidation)
    }
    dir := "ASC"
    if strings.EqualFold(q.Get("order"), "desc") {
        dir = "DESC"
    }
    // tie-breaker по id обязателен, иначе keyset-пагинация «дребезжит»
    return col + " " + dir + ", p.id " + dir, nil
}

Бывает, что без динамического имени таблицы или схемы не обойтись (мультитенантность «схема на клиента», админский конструктор отчётов). Тогда идентификатор не склеивают, а цитируют библиотечной функцией и всё равно проверяют по списку: pgx.Identifier{schema, table}.Sanitize() в pgx или quote_ident() на стороне PostgreSQL. Список существующих тенантов проверяй заранее - цитирование спасает от синтаксической инъекции, но не от «покажи мне схему чужого клиента».

Что ещё говорят про инъекции на собеседовании

• ORM сама по себе не защищает. Склеить строку можно и в GORM: Where("name = '" + s + "'"), Raw, Exec, любой конструктор «сырых» фрагментов. Защищает плейсхолдер, а не ORM.
• Least privilege у роли БД. Приложение ходит под ролью без DROP, без CREATE, без доступа к чужим схемам и без суперправ. Тогда даже успешная инъекция прочитает только то, что и так доступно сервису. Для миграций заводят отдельную роль.
• Ошибки наружу не отдавать. Текст ошибки СУБД подсказывает атакующему имя таблицы, тип колонки, версию сервера. Клиент получает обезличенный 500/400 и trace_id, детали уходят в лог.
• Инъекции бывают и помимо SQL. Тот же класс: NoSQL (оператор $ne в JSON-фильтре Mongo), LDAP, command injection через exec.Command("sh", "-c", user), шаблонизаторы, XPath, заголовки писем. Ответ везде один: не собирать команду строкой. В Go с процессами это особенно просто: exec.Command(name, args...) вообще не запускает shell, если явно не позвать sh -c.
• Обнаружение: линтеры (gosec, правила G201/G202 про конкатенацию в SQL; сам go vet такого не ловит), запрет fmt.Sprintf рядом с db.Query на ревью, WAF как второй эшелон, а не как первый.

XSS: что из этого реально может сделать бэкенд

XSS тоже инъекция, только в HTML: строка пользователя оказывается в разметке, и браузер исполняет её как код. Исполняет у другого пользователя и в контексте нашего origin, то есть с доступом ко всему, что там есть: DOM, localStorage, куки без httpOnly. И, что хуже всего, скрипт может слать запросы к нашему же API от имени жертвы, уже с её сессией.

Отсюда и ответ на вопрос «что тут делает бэкенд». Если фронт написан как SPA, а бэкенд отдаёт только JSON, классический XSS чинится на фронте: React/Vue экранируют по умолчанию, и дыра появляется через dangerouslySetInnerHTML/v-html. Но у бэкенда остаётся четыре рычага, и их надо назвать.

1. Экранирование при рендере - если рендерим мы

В Go разница между двумя пакетами стоит инцидента. text/template подставляет строку как есть. html/template учитывает контекст: парсит шаблон, понимает, куда попадает значение (в текст, в атрибут, в href, внутрь <script>, в CSS), и в каждом месте экранирует по-своему. Контекст нужен потому, что экранировать < и > мало, если значение попадает в атрибут без кавычек или в URL со схемой javascript:.

import "html/template"   // не text/template

var page = template.Must(template.New("p").Parse(`
  <p>Привет, {{.Name}}</p>                     <!-- HTML-контекст -->
  <a href="{{.Site}}">сайт</a>                 <!-- URL-контекст -->
  <script>var u = {{.Name}};</script>          <!-- JS-контекст -->
`))

// Name = `<img src=x onerror=alert(1)>` → в HTML станет &lt;img …&gt;,
//   а в <script> станет корректным JS-литералом "\u003cimg src=x …\u003e".
// Site = `javascript:alert(1)`          → html/template подставит #ZgotmplZ.

Обратная сторона: тип template.HTML отключает экранирование. Нужен он в одном случае: когда вставляем HTML, которому доверяем. Пользовательскому HTML доверять нельзя никогда. Если продукту нужно форматирование (комментарии с разметкой), такой HTML пропускают через санитайзер с белым списком тегов и атрибутов - bluemonday в Go. Чёрный список (вырезать <script>) не работает, обходов десятки: <img onerror>, <svg onload>, <iframe srcdoc>, экзотические кодировки, <scr<script>ipt> для наивной однопроходной замены.

2. Content-Type и X-Content-Type-Options

Браузер решает, исполнять ли содержимое как HTML, по заголовку Content-Type. Если его нет или он неправильный, срабатывает MIME-sniffing: браузер угадывает по первым байтам. Загруженный «аватар», который на самом деле начинается с <html><script> и отдаётся без Content-Type, вполне может исполниться как страница на нашем домене. Отсюда два обязательных пункта:

• всегда выставлять точный Content-Type - application/json; charset=utf-8 для API, реальный тип для файлов, а для скачиваемого пользовательского контента ещё и Content-Disposition: attachment;
• X-Content-Type-Options: nosniff, который запрещает угадывание. Один заголовок закрывает целый класс атак.

Мера посерьёзнее: отдавать пользовательские файлы с другого домена (usercontent.example.net, не поддомен основного). Тогда даже скрипт, который там исполнился, окажется в чужом origin и до сессии на основном домене не дотянется.

3. JSON-эндпоинт как вектор - почему это не паранойя

На фразе «У нас только JSON, XSS невозможен» любят ловить. Превратить JSON-ручку в XSS можно несколькими способами:

• Неверный Content-Type. Тот же JSON, отданный как text/html (или вообще без типа, с включённым sniffing), исполняется. Хватит того, что в теле есть отражённое значение из запроса: {"error":"неизвестный параметр <script>…</script>"}. Классический сценарий: обработчик ошибок отражает err.Error() в ответ. В Go http.Error тут безопасен: он ставит text/plain и X-Content-Type-Options: nosniff. Опасен самописный хелпер без Content-Type: тип тогда угадывает net/http по первым байтам, и <script> в начале тела сделает ответ text/html.
• Отражение в ответе плюс скачивание. Если ручка отдаёт файл с именем, взятым из запроса, и браузер открывает его как документ, контекст снова становится HTML.
• JSONP, легаси-механизм обхода SOP: ответ оборачивается в вызов функции, имя которой пришло в query. Выходит сразу XSS (имя коллбэка попадает в исполняемый код) и полный обход CORS, потому что <script src> уходит куда угодно и с куками. Ответ простой: JSONP не использовать, для кросс-домена есть CORS.
• Ответ, который потом кладут в DOM. Даже идеальный JSON становится XSS, если фронт вставит поле через innerHTML. Формально виноват фронт, но проектная вина общая: не хранить в БД то, что не прошло валидацию, и не отдавать HTML там, где по контракту текст.

// Ответ API: тип выставляем явно и до записи тела, sniffing запрещаем.
func writeJSON(w http.ResponseWriter, status int, v any) {
    w.Header().Set("Content-Type", "application/json; charset=utf-8")
    w.Header().Set("X-Content-Type-Options", "nosniff")
    w.WriteHeader(status)                       // строго после Header().Set

    enc := json.NewEncoder(w)
    enc.SetEscapeHTML(true)                     // дефолт: < > & → \u003c \u003e \u0026
    if err := enc.Encode(v); err != nil {
        // статус и заголовки уже ушли, поменять их нельзя: только логируем
        slog.Error("encode response", "err", err)
    }
}

Про SetEscapeHTML: по умолчанию encoding/json экранирует <, > и & в юникод-последовательности, чтобы JSON можно было безопасно встроить в HTML. Иногда это отключают ради читаемости - и заодно убирают одну из подстраховок.

4. CSP - второй эшелон

Заголовком Content-Security-Policy сервер сообщает браузеру, откуда странице можно грузить скрипты, стили и картинки и разрешён ли инлайн. Экранирование CSP не заменяет, а страхует: если XSS всё-таки просочился, полезная нагрузка не исполнится или не сможет утечь наружу.

# Строгая политика для отрендеренной сервером страницы: nonce на каждый запрос,
# никакого 'unsafe-inline', запрет фреймов и base-тега.
Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-r4nd0m' 'strict-dynamic';
  style-src 'self';
  img-src 'self' data:;
  connect-src 'self' https://api.example.com;
  object-src 'none'; base-uri 'none'; frame-ancestors 'none';
  form-action 'self'

# Чистому JSON-API хватит жёсткого минимума, страниц там нет:
Content-Security-Policy: default-src 'none'; frame-ancestors 'none'; sandbox

• 'unsafe-inline' в script-src почти полностью обесценивает CSP - XSS как раз и исполняется инлайном. Вместо него ставят nonce или хеш скрипта.
• Внедрять политику разумно через Content-Security-Policy-Report-Only плюс report-to: собрать нарушения на проде, вычистить, потом включить в блокирующем режиме.
• frame-ancestors 'none' пришёл на смену X-Frame-Options: DENY и защищает от clickjacking. Старый заголовок оставляют для совместимости.

CSRF: браузер отправляет запрос за пользователя

Cross-Site Request Forgery держится на автоматическом прикреплении учётных данных. Браузер прикладывает куки к запросу, глядя на адрес назначения, а не на того, кто этот запрос инициировал. Значит, чужая страница может заставить браузер жертвы сходить на наш домен - и запрос придёт полностью аутентифицированным.

Прочитать ответ злоумышленник при этом не может. Same-Origin Policy не даст чужому скрипту увидеть тело, статус или заголовки нашего ответа. Поэтому CSRF бьёт по изменяющим операциям: перевод денег, смена email, смена пароля, удаление, выдача прав. Это «слепой» вызов, результат которого атакующему не нужен.

Почему кука уязвима, а Authorization: Bearer - нет

Всё решает то, кто прикрепляет учётные данные. Куку прикрепляет браузер по правилу «домен совпал - приложил», и инициатор запроса ему при этом не важен (без SameSite). Заголовок Authorization проставляет наш JavaScript, который живёт на нашем origin. Чужая страница до него не дотянется - не прочитает токен из localStorage нашего домена и не заставит браузер добавить заголовок. К тому же любой запрос с кастомным заголовком перестаёт быть «простым» и требует CORS-preflight: браузер сначала спросит у сервера разрешения, чужому Origin мы его не дадим, и настоящий запрос просто не уйдёт.

SameSite в деталях

• «Same-site» ≠ «same-origin». Сравнивается registrable domain (eTLD+1), а не полный origin: app.example.com и api.example.com считаются одним site, схема тоже учитывается. Поэтому SameSite не спасает от атаки с захваченного соседнего поддомена.
• Lax защищает не полностью. Форму и fetch он закрывает, а изменяющую операцию, повешенную на GET, нет. Если у нас есть GET /account/delete, атака сводится к простой ссылке или редиректу: top-level навигацию GET-ом Lax пропускает. А где кука без SameSite и браузер не ставит Lax сам, хватит и <img src=…>. Отсюда прямая связь: семантика методов тоже защищает от CSRF.
• Старые браузеры атрибут игнорируют, поэтому для по-настоящему критичных операций SameSite остаётся первым эшелоном, но не единственным.

CSRF-токены: два рабочих паттерна

Идея у обоих одна: потребовать от запроса значение, которое чужой сайт узнать не может. Читать наш ответ он не умеет (SOP), так что любой секрет, выданный на странице, ему недоступен.

• Synchronizer token. Сервер генерирует случайный токен, кладёт его в состояние сессии и отдаёт в HTML (скрытое поле формы или мета-тег), а на изменяющем запросе сверяет пришедшее значение с сохранённым. Надёжнее некуда, но нужно состояние на сервере.
• Double submit cookie обходится без состояния: сервер кладёт случайное значение в отдельную не-httpOnly куку, фронт читает её из JS и дублирует в заголовок X-CSRF-Token, а сервер сравнивает куку и заголовок. Схема работает, потому что чужой сайт не может прочитать куку и тем более проставить заголовок. Слабое место: захваченный поддомен может записать куку на родительский домен. Поэтому в проде берут signed double submit - значение куки привязано к идентификатору сессии через HMAC, и подставить произвольную пару не выйдет.

// Middleware: пропускаем безопасные методы, для остальных сверяем токен.
var safe = map[string]bool{http.MethodGet: true, http.MethodHead: true, http.MethodOptions: true}

func CSRF(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        if safe[r.Method] {
            next.ServeHTTP(w, r)
            return
        }
        // CSRF грозит только сессии в куке. Bearer-запросы пропускаем.
        if strings.HasPrefix(r.Header.Get("Authorization"), "Bearer ") {
            next.ServeHTTP(w, r)
            return
        }
        c, err := r.Cookie("csrf_token")
        hdr := r.Header.Get("X-CSRF-Token")
        // Сравниваем за постоянное время, иначе токен подберут побайтово.
        if err != nil || hdr == "" ||
            subtle.ConstantTimeCompare([]byte(c.Value), []byte(hdr)) != 1 {
            problem(w, http.StatusForbidden, "csrf_failed", "CSRF-токен не совпал")
            return
        }
        next.ServeHTTP(w, r)
    })
}

// Кука с токеном: httpOnly=false, иначе наш же JS её не прочитает.
http.SetCookie(w, &http.Cookie{
    Name: "csrf_token", Value: randomToken(32),
    Path: "/", Secure: true, HttpOnly: false, SameSite: http.SameSiteLaxMode,
})

Go 1.25: http.CrossOriginProtection - защита без токенов и кук

Выше была классика: своё состояние, своя кука, свой заголовок, свой код на фронте. В Go 1.25 в net/http появился CrossOriginProtection, готовый middleware из стандартной библиотеки, который решает ту же задачу вообще без токенов. Из-за него сдвинулась рекомендация по умолчанию, и на собесе это хороший свежий ответ: «для современных браузеров хватает штатного middleware, токены остаются страховкой».

Механика держится на Fetch metadata - служебных заголовках, которые к каждому запросу на HTTPS (и на localhost) добавляет сам браузер. Страница-инициатор не может их ни подделать, ни убрать (в отличие от Referer, который вырезается политикой, и от кастомных заголовков, которые ставит JS). Главный из них, Sec-Fetch-Site, отвечает как раз на тот вопрос, которого не хватало серверу: откуда запрос инициирован. Значения: same-origin, same-site, cross-site и none (пользователь сам ввёл адрес или открыл закладку). Само правило умещается в строку: небезопасный метод при Sec-Fetch-Site, не равном same-origin или none, получает 403. Если заголовка нет вовсе, в ход идёт запасной вариант: хост из Origin сверяется с Host, и при несовпадении запрос тоже отклоняется.

cop := http.NewCrossOriginProtection()

// Свой фронт на другом origin добавляем в белый список.
_ = cop.AddTrustedOrigin("https://admin.example.com")

// Ручки, куда браузер не ходит (вебхуки платёжки, колбэки), пускаем в обход.
cop.AddInsecureBypassPattern("/webhooks/")

// Дефолтный отказ: 403 с текстом. Приводим к своему формату ошибок.
cop.SetDenyHandler(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    problem(w, http.StatusForbidden, "cross_origin_denied", "межсайтовый запрос отклонён")
}))

srv := &http.Server{Addr: ":8080", Handler: cop.Handler(mux)}

// Если решение нужно принимать самому (например, логировать, но пропускать на канарейке):
if err := cop.Check(r); err != nil { /* это межсайтовый небезопасный запрос */ }

Полная таблица решений (проверено запуском на go1.27.0, POST на bank.example):

Sec-Fetch-Site: cross-site                      -> 403  "cross-origin request detected from Sec-Fetch-Site header"
Sec-Fetch-Site: same-site  (соседний поддомен)   -> 403  тоже отказ: проверка по ORIGIN, а не по site
Sec-Fetch-Site: same-origin                     -> 200
Sec-Fetch-Site: none       (адрес ввели руками)  -> 200
нет Sec-Fetch-Site и нет Origin                 -> 200  считаем, что это не браузер: curl, мобилка, сервис
нет Sec-Fetch-Site, Origin != Host              -> 403  "...and/or browser is out of date"
cross-site, но Origin в AddTrustedOrigin        -> 200
cross-site, но путь в AddInsecureBypassPattern  -> 200
GET / HEAD / OPTIONS при любом Sec-Fetch-Site   -> 200  безопасные методы не проверяются вообще

SSRF: сервер идёт туда, куда ему сказал клиент

При Server-Side Request Forgery злоумышленник управляет адресом, по которому наш сервис делает исходящий запрос. Атакующему это ценно, потому что наш сервер стоит внутри периметра: он видит приватную сеть, служебные порты и облачные метаданные, недоступные снаружи. Типовые точки входа: «загрузить картинку по URL», вебхуки, импорт из внешнего источника, генерация PDF/превью по ссылке, прокси-ручка, парсинг og:-разметки для красивого превью ссылки.

// Уязвимо: адрес полностью контролирует клиент.
func fetchAvatar(ctx context.Context, rawURL string) ([]byte, error) {
    resp, err := http.Get(rawURL)     // http://169.254.169.254/latest/meta-data/…
    ...                               // http://localhost:6379/  → Redis по HTTP
}                                     // file:///etc/passwd      → зависит от клиента

• Облачные метаданные. По адресу 169.254.169.254 в AWS/GCP/Azure лежат временные учётные данные роли инстанса. Хватит одного удачного SSRF, и у атакующего ключи от облака. IMDSv2 (обязательный PUT-токен и X-aws-ec2-metadata-token) появился как раз поэтому.
• Внутренние сервисы - админки без аутентификации «потому что они не торчат наружу», Kubernetes API, Consul, Elasticsearch, Prometheus, панель самого приложения.
• Сканирование сети. По времени ответа и коду ошибки атакующий картирует внутренние адреса и открытые порты, даже если тело ответа ему не возвращают (blind SSRF).
• Смена протокола через file://, gopher://, dict://. Если библиотека поддерживает эти схемы, из HTTP-запроса можно собрать произвольный TCP-пакет и, например, отдать команду Redis.

Как защищаться - по убыванию надёжности

1. Allowlist. В идеале сервис вообще не ходит по произвольным URL: есть список разрешённых хостов или заранее зарегистрированные интеграции, всё остальное отвергается. Только эта защита не проигрывает гонку с обходами.
2. Отдельный egress-прокси. Весь исходящий трафик сервиса идёт через прокси, у которого своя политика; сам под сидит в сетевой политике, запрещающей прямые соединения во внутренние подсети. Тогда даже ошибка в коде не даёт доступа.
3. Запрет приватных диапазонов на этапе соединения. Проверять надо не строку URL, а IP, к которому реально подключается сокет. Проверка «распарсили URL → отрезолвили → сравнили» уязвима к DNS rebinding: между проверкой и соединением DNS отдаёт другой адрес (TOCTOU). В Go это решает хук Control у диалера - его вызывают уже с готовым адресом, прямо перед connect.

// Диалер, который отказывается соединяться с приватными и служебными адресами.
// Control зовут после резолва и до connect: DNS rebinding не пройдёт.
var blocked = []netip.Prefix{
    netip.MustParsePrefix("0.0.0.0/8"),      netip.MustParsePrefix("10.0.0.0/8"),
    netip.MustParsePrefix("100.64.0.0/10"),  netip.MustParsePrefix("127.0.0.0/8"),
    netip.MustParsePrefix("169.254.0.0/16"), netip.MustParsePrefix("172.16.0.0/12"),
    netip.MustParsePrefix("192.168.0.0/16"), netip.MustParsePrefix("::1/128"),
    netip.MustParsePrefix("fc00::/7"),       netip.MustParsePrefix("fe80::/10"),
    netip.MustParsePrefix("::/128"),         // [::] ядро соединит с loopback
}

func safeControl(network, address string, _ syscall.RawConn) error {
    if network != "tcp4" && network != "tcp6" {
        return fmt.Errorf("ssrf: сеть %s запрещена", network)
    }
    host, _, err := net.SplitHostPort(address)
    if err != nil {
        return err
    }
    ip, err := netip.ParseAddr(host)
    if err != nil {
        return err
    }
    ip = ip.Unmap()                       // ::ffff:169.254.169.254 → 169.254.169.254
    ip = ip.WithZone("")                  // для fe80::1%lo0 Contains всегда false
    for _, p := range blocked {
        if p.Contains(ip) {
            return fmt.Errorf("ssrf: адрес %s запрещён", ip)
        }
    }
    return nil
}

var safeClient = &http.Client{
    Timeout: 5 * time.Second,
    Transport: &http.Transport{
        DialContext: (&net.Dialer{Timeout: 3 * time.Second, Control: safeControl}).DialContext,
    },
    // Редирект даёт новый URL, выбранный не нами: проверяем каждый прыжок.
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        if len(via) >= 3 {
            return errors.New("ssrf: слишком много редиректов")
        }
        return checkScheme(req.URL)       // только http/https, порт из разрешённых
    },
}

IDOR и broken access control - самая частая реальная дыра

В OWASP Top 10 первое место (A01) занимает не инъекция, а сломанный контроль доступа. Причина простая: инъекцию ловит линтер, и выглядит она везде одинаково, а «этот заказ принадлежит этому пользователю» остаётся бизнес-правилом. Его пишут руками в каждом обработчике, и достаточно один раз забыть.

Самый узнаваемый частный случай называется IDOR: идентификатор объекта приходит из запроса и используется без проверки прав на этот конкретный объект.

// Уязвимо: middleware проверил, что пользователь аутентифицирован,
// но никто не проверил, что заказ принадлежит именно ему.
func (h *Handler) GetOrder(w http.ResponseWriter, r *http.Request) {
    id, _ := strconv.ParseInt(r.PathValue("id"), 10, 64)
    order, err := h.repo.GetByID(r.Context(), id)   // ← /v1/orders/1235 вместо 1234
    ...
}

// Правильно: владение проверяется в самом запросе, отдельную проверку
// легко забыть. Условие уезжает в WHERE.
func (h *Handler) GetOrder(w http.ResponseWriter, r *http.Request) {
    id, _ := strconv.ParseInt(r.PathValue("id"), 10, 64)
    uid := auth.UserID(r.Context())
    order, err := h.repo.GetForUser(r.Context(), id, uid)  // WHERE id=$1 AND user_id=$2
    if errors.Is(err, sql.ErrNoRows) {
        problem(w, http.StatusNotFound, "not_found", "Заказ не найден")
        return
    }
    ...
}

• Проверять владение в том же запросе к БД, а не отдельным if после чтения. Так забыть проверку структурно труднее, и гонок нет. Для сложных правил пишут явную функцию can(ctx, subject, action, object) и вызывают её в сервисном слое, где объект уже известен.
• Отдавать 404, а не 403, если даже факт существования объекта выдаёт информацию. 403 подтверждает, что заказ с таким id есть.
• Непредсказуемые идентификаторы смягчают риск, но не защищают. UUIDv4 вместо автоинкремента убирает тривиальный перебор, но id утекают в логи, в реферер, в шаринг ссылок. «Секретный URL» работает как контроль доступа только там, где так задумано (одноразовые ссылки с TTL).
• Массовые операции и вложенные ресурсы. PATCH /v1/orders со списком id, GET /v1/users/{uid}/orders/{oid}, экспорт в CSV, GraphQL-резолвер вложенного поля: здесь проверку владения забывают чаще всего, потому что она нужна для каждого элемента.
• Fail closed. По умолчанию роутер требует авторизацию, а публичные маршруты помечаются явно. Полезный тест: пройтись по всем зарегистрированным маршрутам и убедиться, что у каждого есть политика, иначе новый эндпоинт однажды приедет голым.
• Функциональный уровень. Во втором частом случае защищать надо не объект, а действие: /admin/* открыт без роли, потому что «ссылки на него нет в интерфейсе». Скрытая кнопка доступ не контролирует.

Mass assignment: почему входной JSON не биндят в доменную модель

Соблазн понятен: структура уже есть, теги json тоже, зачем писать вторую. Но json.NewDecoder(r.Body).Decode заполняет те поля, которые прислали, а прислать могут любые - включая те, о которых клиент знать не должен.

// Доменная модель, она же модель БД, она же тело запроса. Так делать нельзя.
type User struct {
    ID        int64  `json:"id"`
    Email     string `json:"email"`
    IsAdmin   bool   `json:"is_admin"`      // ← {"is_admin": true}
    Balance   int64  `json:"balance"`       // ← {"balance": 999999}
    CreatedAt time.Time `json:"created_at"`
}

func (h *Handler) UpdateProfile(w http.ResponseWriter, r *http.Request) {
    var u User
    json.NewDecoder(r.Body).Decode(&u)      // клиент задаёт любое поле
    h.repo.Update(r.Context(), &u)          // и оно уезжает в UPDATE
}

Правильно заводить отдельный тип на каждое направление: DTO запроса, доменная модель, DTO ответа. Это явное описание контракта, а не «лишний слой ради слоя»: какие поля клиент может задать и какие мы готовы показать.

// Клиенту разрешено прислать ровно два поля.
type updateProfileReq struct {
    DisplayName string `json:"display_name" validate:"required,min=1,max=64"`
    Bio         string `json:"bio"          validate:"max=500"`
}

func (h *Handler) UpdateProfile(w http.ResponseWriter, r *http.Request) {
    var req updateProfileReq
    dec := json.NewDecoder(http.MaxBytesReader(w, r.Body, 32<<10))
    dec.DisallowUnknownFields()                   // "is_admin" → явная ошибка 400
    if err := dec.Decode(&req); err != nil {
        problem(w, http.StatusBadRequest, "malformed_json", "Тело запроса неразборчиво")
        return
    }
    if err := h.validate.Struct(req); err != nil { ... }

    // Из DTO в домен поля переносим явно. Про забытое новое поле компилятор
    // не напомнит: это ловят тест или линтер exhaustruct.
    err := h.svc.UpdateProfile(r.Context(), auth.UserID(r.Context()),
        service.ProfilePatch{DisplayName: req.DisplayName, Bio: req.Bio})
    ...
}

CORS: что это на самом деле

Из всей секции CORS понимают хуже всего. Первым делом стоит сказать: CORS ослабляет Same-Origin Policy в браузере и сервер ни от чего не защищает. По умолчанию скрипт со страницы app.example.com не может прочитать ответ от api.example.com. Через CORS сервер говорит браузеру: «этому origin читать мой ответ можно». Запрещать CORS не умеет, только разрешать.

Simple request против preflight

Браузер сначала решает, «простой» ли запрос. Простой уходит сразу, а отдавать ли ответ скрипту, браузер решает уже потом. Перед непростым он шлёт отдельный запрос OPTIONS (preflight), и, если политика не подошла, настоящий запрос не уходит вовсе. На практике разница такая: preflight предотвращает побочный эффект, а simple его не останавливает.

Выходит, что почти любой современный JSON-API всегда идёт с preflight - Content-Type: application/json и заголовок Authorization выводят запрос из «простых». Поэтому HTML-форма не подделает JSON-запрос, если сервер строго проверяет Content-Type: форма с text/plain умеет прислать тело, похожее на JSON. А токен в заголовке не подвержен CSRF по другой причине: браузер не прикладывает его сам, как куку.

Заголовки: кто за что отвечает

Типичные ошибки настройки

• Allow-Origin: * вместе с Allow-Credentials: true. Спецификация это прямо запрещает, и браузер отклонит ответ. Логика простая: «любой сайт» плюс «с куками пользователя» дают произвольной странице право читать личные данные жертвы. Выход один: отдавать конкретный origin.
• Отражение Origin без проверки. Классическая «починка» предыдущего пункта: w.Header().Set("Access-Control-Allow-Origin", r.Header.Get("Origin")) плюс Allow-Credentials: true. По сути это тот же * с куками, только спецификацию удалось обмануть: любой сайт получает право читать ответы с сессией жертвы. Одна из самых частых находок на пентесте.
• Слабое сравнение origin. strings.HasPrefix(o, "https://example.com") пропускает https://example.com.evil.net, а strings.Contains(o, "example.com") пропустит ещё и https://evil-example.com. Сравнивать нужно полный origin, на точное совпадение с заранее заданным множеством.
• Забытый Vary: Origin. Если ответ кэшируется (CDN, обратный прокси, кэш браузера), без Vary ответ с Allow-Origin: https://a.example.com уйдёт клиенту с origin b.example.com - и наоборот. Смотря в какую сторону промахнулся кэш, получится либо неработающий фронт, либо утечка разрешения. Ставить его надо на всех ответах, где Allow-Origin вычисляется динамически.
• null в белом списке. Origin null присылают песочницы iframe sandbox, локальные файлы и некоторые редиректы, так что разрешить его значит впустить кого угодно.
• Preflight не доходит до обработчика. На OPTIONS нужно отвечать до аутентификации: браузер не прикладывает к нему ни кук, ни Authorization, поэтому auth-middleware вернёт 401, и весь запрос упадёт. Выглядит это как «CORS-ошибка, хотя всё настроено».
• CORS вместо авторизации. Для публичного API разрешить всё (* без credentials) совершенно нормально. Ошибка в другом: считать API «закрытым», раз в CORS перечислены только свои домены. См. первый пункт про curl.

// Аккуратный CORS-middleware: точное сравнение, Vary всегда, OPTIONS до auth.
func CORS(allowed map[string]bool) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            origin := r.Header.Get("Origin")
            // Vary ставим всегда, даже когда origin не разрешён и заголовков не будет:
            // иначе кэш смешает ответы для разных origin.
            w.Header().Add("Vary", "Origin")

            if origin != "" && allowed[origin] {
                w.Header().Set("Access-Control-Allow-Origin", origin) // конкретный, не *
                w.Header().Set("Access-Control-Allow-Credentials", "true")
                w.Header().Set("Access-Control-Expose-Headers",
                    "X-Request-Id, X-RateLimit-Remaining, Retry-After")
            }

            if r.Method == http.MethodOptions &&
                r.Header.Get("Access-Control-Request-Method") != "" {
                w.Header().Add("Vary", "Access-Control-Request-Method")
                w.Header().Add("Vary", "Access-Control-Request-Headers")
                if origin != "" && allowed[origin] {
                    w.Header().Set("Access-Control-Allow-Methods",
                        "GET, POST, PUT, PATCH, DELETE")
                    w.Header().Set("Access-Control-Allow-Headers",
                        "Authorization, Content-Type, X-Request-Id, Idempotency-Key")
                    w.Header().Set("Access-Control-Max-Age", "600")
                }
                w.WriteHeader(http.StatusNoContent) // отвечаем до auth-middleware
                return
            }
            next.ServeHTTP(w, r)
        })
    }
}

Rate limiting

У ограничения частоты несколько задач, и на собеседовании их полезно развести. Оно не даёт перебирать пароли и токены, мешает скрейпить и выкачивать базу, спасает от случайного DoS собственным клиентом с ретраями, честно делит ёмкость между тенантами и, наконец, бережёт деньги, если за нами платный внешний API. От «настоящего» DDoS на канал приложение не защитит - это уровень CDN и провайдера.

Все алгоритмы решают одно: пропустить запрос или отклонить. Различаются они на всплеске, и проще всего это увидеть, если прогнать через все четыре один и тот же трафик.

В двух из четырёх названий стоит слово bucket - «ведро». Это метафора счётчика, и она честная ровно до дна. Token bucket: в ведро фиксированной ёмкости с постоянной скоростью капают разрешения (их и называют «токенами», к токенам аутентификации из главы 10.3 они отношения не имеют). Каждый запрос забирает одно разрешение; ведро пусто - отказ. Пока клиент молчал, ведро наполнялось - отсюда и право на всплеск размером ровно в ёмкость ведра. Leaky bucket: тут ведро наполняют сами запросы, а вытекает оно с постоянной скоростью, поэтому на выходе трафик всегда идеально ровный; переполнилось ведро - отказ. Физически «ведро» хранится в Redis как два числа: сколько в нём сейчас и когда его трогали в прошлый раз.

Локальный лимитер: golang.org/x/time/rate

Готовый token bucket лежит в стандартном расширении. Конструктор rate.NewLimiter(r, b) принимает скорость долива и ёмкость, те самые две ручки из таблицы выше. Спросить его о решении можно тремя способами, и путать их не стоит:

// r - токенов в секунду, b - ёмкость ведра (максимальный всплеск).
lim := rate.NewLimiter(rate.Every(time.Second/10), 20)  // 10 rps, burst 20

lim.Allow()          // не ждать: true/false сразу, для HTTP-хендлера
lim.Wait(ctx)        // ждать токен до дедлайна ctx, для фонового воркера
lim.Reserve()        // забронировать и узнать, сколько ждать: r.Delay()

В HTTP почти всегда нужен Allow. Wait внутри хендлера копит ждущие горутины, а за ними и таймауты: вместо быстрого 429 клиент получает зависший запрос. Wait хорош там, где мы сами исходящая сторона, например когда обходим сторонний API с лимитом 100 rps.

// Лимитер на ключ с вытеснением: без уборки map растёт бесконечно, это утечка.
type Limiters struct {
    mu   sync.Mutex
    m    map[string]*entry
    r    rate.Limit
    b    int
}
type entry struct {
    lim  *rate.Limiter
    seen time.Time
}

func (l *Limiters) Get(key string) *rate.Limiter {
    l.mu.Lock()
    defer l.mu.Unlock()
    e, ok := l.m[key]
    if !ok {
        e = &entry{lim: rate.NewLimiter(l.r, l.b)}
        l.m[key] = e
    }
    e.seen = time.Now()
    return e.lim
}

// Отдельная горутина раз в минуту выкидывает ключи, не встречавшиеся 10 минут.
// Или LRU фиксированного размера: память под нагрузкой предсказуема.

func RateLimit(l *Limiters, keyOf func(*http.Request) string) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            if !l.Get(keyOf(r)).Allow() {
                w.Header().Set("Retry-After", "1")
                problem(w, http.StatusTooManyRequests, "rate_limited",
                    "Слишком много запросов, повторите позже")
                return
            }
            next.ServeHTTP(w, r)
        })
    }
}

Распределённый лимитер на Redis

Когда лимит должен быть общим для всех инстансов, состояние переезжает в общее хранилище. Redis тут хорош по двум причинам. Он быстрый, а лимитер стоит на горячем пути каждого запроса. И он однопоточный, поэтому Lua-скрипт выполняется атомарно - между чтением счётчика и его записью никакой другой под не вклинится.

// Token bucket в Redis: одно ведро на ключ, весь read-modify-write внутри Lua.
// KEYS[1] - ключ ведра.  ARGV: now_ms, rate (токенов в секунду), burst, cost.
var tokenBucket = redis.NewScript(`
local key   = KEYS[1]
local now   = tonumber(ARGV[1])
local rate  = tonumber(ARGV[2])
local burst = tonumber(ARGV[3])
local cost  = tonumber(ARGV[4])

local st     = redis.call('HMGET', key, 'tokens', 'ts')
local tokens = tonumber(st[1])
local ts     = tonumber(st[2])

if tokens == nil then          -- первое обращение: ведро полное
  tokens = burst
  ts     = now
end

-- долив за прошедшее время, с потолком в ёмкость ведра
local delta = math.max(0, now - ts) / 1000.0
tokens = math.min(burst, tokens + delta * rate)
ts     = now

local allowed = 0
local retry   = 0
if tokens >= cost then
  tokens  = tokens - cost
  allowed = 1
else
  -- сколько миллисекунд ждать, пока накапает недостающее
  retry = math.ceil(((cost - tokens) / rate) * 1000)
end

redis.call('HSET', key, 'tokens', tokens, 'ts', ts)
-- TTL с запасом на полное восстановление ведра: без него ключи копятся вечно
redis.call('PEXPIRE', key, math.ceil((burst / rate) * 1000) + 1000)

return { allowed, math.floor(tokens), retry }
`)

type Decision struct {
    Allowed   bool
    Remaining int
    RetryIn   time.Duration
}

func (l *RedisLimiter) Allow(ctx context.Context, key string, cost int) (Decision, error) {
    // Жёсткий таймаут: из-за лимитера запрос не должен упасть по таймауту.
    ctx, cancel := context.WithTimeout(ctx, 50*time.Millisecond)
    defer cancel()

    res, err := tokenBucket.Run(ctx, l.rdb, []string{"rl:tb:" + key},
        time.Now().UnixMilli(), l.rate, l.burst, cost).Int64Slice()
    if err != nil {
        // fail-open: лимитер сломался, а сервис продолжает работать.
        // Нужны метрика и алерт, иначе поломку никто не заметит.
        l.failures.Inc()
        return Decision{Allowed: true}, err
    }
    return Decision{
        Allowed:   res[0] == 1,
        Remaining: int(res[1]),
        RetryIn:   time.Duration(res[2]) * time.Millisecond,
    }, nil
}

Что отдавать клиенту

Отказ должен быть машиночитаемым, чтобы клиент понял, что делать дальше, не разбирая текст.

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Retry-After: 5                          # секунды либо HTTP-дата
RateLimit-Policy: "default";q=100;w=60  # черновик IETF: квота 100 на 60 секунд
RateLimit: "default";r=0;t=5            # осталось 0, окно освободится через 5 с
X-RateLimit-Limit: 100                  # де-факто стандарт, его понимают все SDK
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1756192846           # unix-время сброса

{"type":"https://api.example.com/errors/rate-limited",
 "title":"Слишком много запросов","status":429,
 "detail":"Лимит 100 запросов в минуту исчерпан","retry_after":5}

• Retry-After обязателен. Без него клиент начнёт ретраить сразу и сделает только хуже. Тот же заголовок уместен на 503 при перегрузке.
• Заголовки лимита отдавать и на успешных ответах, чтобы вежливый клиент притормозил до того, как упрётся. Не забыть добавить их в Access-Control-Expose-Headers, иначе браузерный SPA их не увидит.
• 429 против 503. 429 значит «конкретно ты превысил свою квоту», а 503 (в идеале с Retry-After) значит «плохо всему сервису». Смешивать их вредно: алерты на них настраивают по-разному, и клиенты реагируют по-разному.
• Лишнего о лимитах не раскрывать. Для анонимных запросов и для эндпоинта логина точные цифры «осталось 0 из 5» подсказывают перебиральщику ритм. Там достаточно 429 и Retry-After.
• Ответ 429 должен быть дешёвым. Ходить в БД, писать подробный лог на каждый отказ и рендерить тяжёлое тело незачем - иначе лимитер сам становится вектором DoS. Логировать лучше агрегатами, а метрику вести счётчиком с меткой причины.
• Со стороны клиента на 429 отвечают экспоненциальным backoff с джиттером, соблюдают Retry-After и ставят circuit breaker. Если вся армия клиентов ретраит без джиттера, получается синхронный «стук» ровно через N секунд.

Где ставить и по какому ключу считать

Правильный ответ: оба уровня. И это не компромисс, у уровней просто разные задачи: периметр отсекает объём и мусор, приложение следит за бизнес-квотами. На собеседовании хорошо звучит так: «грубый лимит - как можно раньше и как можно дешевле; точный лимит - там, где есть контекст».

// trustedProxies - сколько НАШИХ прокси стоит перед сервисом (обычно 1–2).
func clientIP(r *http.Request, trustedProxies int) netip.Addr {
    peer, _ := netip.ParseAddrPort(r.RemoteAddr)   // это подделать нельзя
    if trustedProxies == 0 {
        return peer.Addr()
    }
    // все строки заголовка: прокси может дописать свою отдельной строкой
    parts := strings.Split(strings.Join(r.Header.Values("X-Forwarded-For"), ","), ",")
    idx := len(parts) - trustedProxies             // отсчёт СПРАВА
    if idx < 0 || idx >= len(parts) {
        return peer.Addr()                         // список короче ожидаемого - не верим
    }
    ip, err := netip.ParseAddr(strings.TrimSpace(parts[idx]))
    if err != nil {
        return peer.Addr()
    }
    return ip.Unmap()
}
// Альтернатива, если инфраструктура позволяет: заголовок, который наш edge
// ПЕРЕЗАПИСЫВАЕТ (не дополняет) - CF-Connecting-IP, True-Client-IP,
// либо стандартный Forwarded из RFC 7239. Всё, что пришло снаружи, стирается.

Ретраи-дубли: идемпотентность и дедупликация

Эту задачу часто путают с rate limiting, хотя она отдельная. Rate limiting защищает от слишком многих запросов, идемпотентность - от повторов одного и того же. За повторами почти никогда не стоит злой умысел: оборвался ответ, клиент словил таймаут, сработал автоматический ретрай библиотеки, пользователь дважды нажал кнопку, брокер доставил сообщение at-least-once. Сам запрос при этом выполнился - потерялся только ответ.

Механика Idempotency-Key разобрана в главе 10.1. Для безопасности и надёжности в ней важны три вещи.

• Ключ занимают до внешнего эффекта. Строку в idempotency_keys с UNIQUE и статусом in_progress вставляют раньше, чем идут в платёжный шлюз. Тогда параллельный дубль упрётся в конфликт уникальности и вторую оплату не запустит. Порядок «сходили в банк → записали ключ» не спасает вообще: проблема живёт как раз между этими двумя шагами.
• Ключ привязан к субъекту и к телу. Уникальна пара (user_id, key), иначе через чужой ключ можно прочитать чужой сохранённый ответ. Плюс хеш тела: тот же ключ с другим телом означает ошибку клиента (422), старый ответ на него не отдают.
• Сохраняют сам ответ, одного факта мало. Повтор должен получить тот же статус и то же тело, что и оригинал, иначе клиент, потерявший первый ответ, так и не узнает результата.

Есть и второй, независимый механизм: дедупликация по естественному ключу. Она нужна там, где ключ идемпотентности прислать некому: входящие вебхуки, сообщения из брокера, импорт файлов. Логика та же, только идентификатор берут из полезной нагрузки.

// Вебхук от платёжной системы: доставка at-least-once, дубли неизбежны.
// Уникальный индекс делает вторую вставку конфликтом, а не вторым эффектом.
func (s *Service) HandleWebhook(ctx context.Context, ev Event) error {
    tx, err := s.db.BeginTx(ctx, nil)
    if err != nil { return err }
    defer tx.Rollback()

    // UNIQUE (provider, event_id)
    res, err := tx.ExecContext(ctx, `
        INSERT INTO processed_events (provider, event_id, received_at)
        VALUES ($1, $2, now())
        ON CONFLICT (provider, event_id) DO NOTHING`, ev.Provider, ev.ID)
    if err != nil { return err }

    if n, _ := res.RowsAffected(); n == 0 {
        return nil          // уже обработано: тихо отвечаем 200, иначе провайдер будет ретраить вечно
    }
    if err := s.apply(ctx, tx, ev); err != nil { return err }
    return tx.Commit()      // отметка и эффект коммитятся одной транзакцией
}

• Дедупликация и эффект живут в одной транзакции. Если отметить «обработано» в Redis, а потом упасть на записи в БД, событие потеряется навсегда. Проще всего сделать это корректно одной транзакцией БД; Redis годится как быстрый фильтр перед ней, но источником истины его делать нельзя.
• Проверять подпись вебхука (HMAC от тела с общим секретом, constant-time сравнение) и метку времени - иначе перехваченный когда-то запрос можно проиграть заново (replay). Подпись считают по сырому телу, до парсинга JSON: пересериализация меняет байты.
• TTL у таблицы дедупликации. Хранить ключи вечно нельзя, но окно должно с запасом перекрывать политику ретраев провайдера (Stripe, например, ретраит до трёх суток).
• Отвечать быстро. Обработку вебхука лучше свести к «проверил подпись → положил в очередь → 200». Если обрабатывать долго и синхронно, провайдер отвалится по таймауту и пришлёт ретрай, то есть медленный обработчик сам плодит дубли.

Валидация входных данных

Валидация не сводится к «проверить, что поле не пустое». Она явно описывает множество допустимых входов и стоит на границе системы. Всё, что не описано, отвергается, поэтому валидация, помимо удобства, ещё и защищает.

Где валидировать

• На границе, сразу после разбора запроса, проверяют синтаксис и формат: типы, диапазоны, длины, обязательность, регулярки. На ошибку отвечают 400 (тело неразборчиво) или 422 (разобрано, но не проходит правила).
• В домене живут бизнес-инварианты, которым нужен контекст: «дата окончания позже даты начала», «сумма не превышает остаток», «этот статус недостижим из текущего». Их место в сервисном слое, потому что они нужны любому вызывающему: HTTP, gRPC, CLI-команде, консьюмеру из брокера.
• В базе - последняя линия: NOT NULL, CHECK, UNIQUE, внешние ключи. Это единственный уровень, который переживёт баг в коде и ручной UPDATE из psql.
• На фронте проверяют только ради UX: это дублирование, защиты оно не даёт.

go-playground/validator и кастомные правила

type createOrderReq struct {
    Email    string    `json:"email"     validate:"required,email,max=254"`
    Currency string    `json:"currency"  validate:"required,iso4217"`
    Amount   int64     `json:"amount"    validate:"required,gt=0,lte=100000000"`
    Comment  string    `json:"comment"   validate:"max=500"`
    DeliverAt time.Time `json:"deliver_at" validate:"required,gt"`   // gt без числа у времени: позже now
    Items    []item    `json:"items"     validate:"required,min=1,max=100,dive"`
    Phone    string    `json:"phone"     validate:"omitempty,e164"`
}

// Валидатор создаётся один раз: он кэширует разбор тегов через reflect,
// а пересоздание на каждый запрос заметно бьёт по производительности.
var validate = func() *validator.Validate {
    v := validator.New(validator.WithRequiredStructEnabled())

    // Имена полей в ошибках берём из json-тегов, чтобы наружу уезжал
    // контракт API, а не имена полей Go.
    v.RegisterTagNameFunc(func(f reflect.StructField) string {
        name := strings.SplitN(f.Tag.Get("json"), ",", 2)[0]
        if name == "-" { return "" }
        return name
    })

    // Кастомное правило: слаг статьи.
    var slugRe = regexp.MustCompile(`^[a-z0-9]+(?:-[a-z0-9]+)*$`)
    v.RegisterValidation("slug", func(fl validator.FieldLevel) bool {
        s := fl.Field().String()
        return len(s) <= 80 && slugRe.MatchString(s)
    })

    // Правило уровня структуры: когда одно поле зависит от другого.
    v.RegisterStructValidation(func(sl validator.StructLevel) {
        r := sl.Current().Interface().(createOrderReq)
        if r.Currency == "RUB" && r.Amount < 100 {
            sl.ReportError(r.Amount, "amount", "Amount", "min_rub", "")
        }
    }, createOrderReq{})
    return v
}()

Ошибки валидатора нельзя отдавать наружу как есть: текст Key: 'createOrderReq.amount' Error:Field validation for 'amount' failed on the 'gt' tag раскрывает внутренние имена и нечитаем для клиента. Их превращают в структуру «поле → код ошибки», совместимую с общим форматом ошибок из главы 10.1.

func validationProblem(err error) *Problem {
    var ve validator.ValidationErrors
    if !errors.As(err, &ve) {
        return &Problem{Status: 400, Code: "bad_request", Title: "Некорректный запрос"}
    }
    p := &Problem{Status: 422, Code: "validation_failed", Title: "Проверьте поля формы"}
    for _, fe := range ve {
        p.Errors = append(p.Errors, FieldError{
            Field: fe.Field(),   // "amount" благодаря RegisterTagNameFunc
            Code:  fe.Tag(),     // "gt", "required", "email" - машиночитаемо
            // Текст для человека собираем сами; сообщение библиотеки наружу не отдаём.
            Message: humanize(fe),
        })
    }
    return p
}

HTTPS everywhere и security-заголовки

TLS обязателен везде, включая внутренние вызовы: сеть внутри периметра прослушивается ровно так же, а модель «мягкая внутри, твёрдая снаружи» разваливается от одной скомпрометированной машины. Минимум на практике: TLS 1.2+ (лучше 1.3), автоматические сертификаты, редирект 80 → 443. Межсервисный трафик закрывают mTLS, обычно через service mesh, чтобы не ротировать сертификаты руками.

func SecurityHeaders(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        h := w.Header()
        // HSTS имеет смысл только на HTTPS-ответе: по http браузер его игнорирует,
        // а на localhost он ещё и мешает разработке.
        if r.TLS != nil {
            h.Set("Strict-Transport-Security", "max-age=31536000; includeSubDomains")
        }
        h.Set("X-Content-Type-Options", "nosniff")
        h.Set("X-Frame-Options", "DENY")
        h.Set("Referrer-Policy", "strict-origin-when-cross-origin")
        h.Set("Content-Security-Policy", "default-src 'none'; frame-ancestors 'none'")
        h.Set("Cache-Control", "no-store")
        // Server и X-Powered-By net/http сам не ставит. А Del тут не помог бы:
        // он выполняется раньше хендлера, который мог их выставить.
        next.ServeHTTP(w, r)
    })
}

q := "SELECT id, email FROM users WHERE id = " + raw   // raw = "1 OR 1=1 --"
row := db.QueryRowContext(ctx, q)

row := db.QueryRowContext(ctx, "SELECT id, email FROM users WHERE id = $1", raw)

var sortable = map[string]string{"created_at": "p.created_at", "views": "p.views_count"}
col, ok := sortable[q.Get("sort")]      // неизвестный ключ → 400, а не склейка
dir := "ASC"; if strings.EqualFold(q.Get("order"), "desc") { dir = "DESC" }

cop := http.NewCrossOriginProtection()
_ = cop.AddTrustedOrigin("https://admin.example.com") // честный фронт на другом origin
cop.AddInsecureBypassPattern("/webhooks/")            // ручки, куда браузер не ходит
srv := &http.Server{Handler: cop.Handler(mux)}        // всё, защита включена

var safeClient = &http.Client{
    Timeout: 5 * time.Second,
    Transport: &http.Transport{
        DialContext: (&net.Dialer{Control: safeControl}).DialContext, // блокирует 10/8, 127/8, 169.254/16, fc00::/7 …
    },
    CheckRedirect: func(r *http.Request, via []*http.Request) error {
        if len(via) >= 3 { return errors.New("too many redirects") }
        return checkScheme(r.URL)   // за редиректом новый адрес, проверяем каждый прыжок
    },
}

// Middleware проверил, что пользователь аутентифицирован.
// Что заказ его, не проверил никто. /v1/orders/1235 вместо 1234.
order, err := repo.GetByID(ctx, id)

// Правильно: владение уезжает в WHERE и его нельзя «забыть проверить».
order, err := repo.GetForUser(ctx, id, auth.UserID(ctx))   // WHERE id=$1 AND user_id=$2

type User struct {
    ID int64 `json:"id"`; Email string `json:"email"`
    IsAdmin bool `json:"is_admin"`; Balance int64 `json:"balance"`
}
var u User
json.NewDecoder(r.Body).Decode(&u)   // {"is_admin": true, "balance": 999999}
repo.Update(ctx, &u)                 // и это уезжает в UPDATE

type updateProfileReq struct {          // ровно то, что клиенту разрешено прислать
    DisplayName string `json:"display_name" validate:"required,max=64"`
    Bio         string `json:"bio"          validate:"max=500"`
}
dec := json.NewDecoder(http.MaxBytesReader(w, r.Body, 32<<10))
dec.DisallowUnknownFields()
// … и перенос в домен поле за полем (забытое новое поле ловят тест или exhaustruct)

→ OPTIONS /v1/orders/42
  Origin: https://app.example.com
  Access-Control-Request-Method: DELETE
  Access-Control-Request-Headers: authorization, content-type

← 204 No Content
  Access-Control-Allow-Origin: https://app.example.com
  Access-Control-Allow-Methods: GET, POST, DELETE
  Access-Control-Allow-Headers: authorization, content-type
  Access-Control-Allow-Credentials: true
  Access-Control-Max-Age: 600
  Vary: Origin

→ DELETE /v1/orders/42          # только теперь уходит боевой запрос
← 200 OK + Access-Control-Allow-Origin  # заголовок обязателен и здесь

lim := rate.NewLimiter(rate.Every(time.Second/10), 20) // 10 rps, burst 20 - это token bucket
lim.Allow()     // не ждать: для HTTP-хендлера
lim.Wait(ctx)   // ждать токен: для исходящих вызовов и фоновых воркеров
lim.Reserve()   // забронировать и узнать задержку

// Token bucket целиком внутри одного атомарного вызова.
var tokenBucket = redis.NewScript(`
local st     = redis.call('HMGET', KEYS[1], 'tokens', 'ts')
local tokens = tonumber(st[1]); local ts = tonumber(st[2])
local now, rate, burst, cost = tonumber(ARGV[1]), tonumber(ARGV[2]), tonumber(ARGV[3]), tonumber(ARGV[4])
if tokens == nil then tokens = burst; ts = now end
tokens = math.min(burst, tokens + math.max(0, now - ts) / 1000.0 * rate)
local allowed, retry = 0, 0
if tokens >= cost then tokens = tokens - cost; allowed = 1
else retry = math.ceil(((cost - tokens) / rate) * 1000) end
redis.call('HSET', KEYS[1], 'tokens', tokens, 'ts', now)
redis.call('PEXPIRE', KEYS[1], math.ceil((burst / rate) * 1000) + 1000)
return { allowed, math.floor(tokens), retry }
`)

// Доверяем ровно тому числу своих прокси, которое реально стоит перед сервисом,
// и отсчитываем справа налево. r.RemoteAddr подделать нельзя.
idx := len(parts) - trustedProxies
if idx < 0 || idx >= len(parts) { return peerAddr }   // список короче ожидаемого, не верим

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Retry-After: 5                      # желателен: секунды или HTTP-дата
X-RateLimit-Limit: 100              # де-факто стандарт, понимают все SDK
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1756192846       # unix-время сброса
RateLimit-Policy: "default";q=100;w=60   # черновик IETF, постепенно вытесняет X-
RateLimit: "default";r=0;t=5

{"type":"…/errors/rate-limited","title":"Слишком много запросов",
 "status":429,"detail":"Лимит 100 запросов в минуту исчерпан","retry_after":5}

// UNIQUE (provider, event_id): вторая вставка становится конфликтом, а не вторым эффектом.
res, err := tx.ExecContext(ctx, `INSERT INTO processed_events (provider, event_id)
    VALUES ($1,$2) ON CONFLICT DO NOTHING`, ev.Provider, ev.ID)
if err != nil {
    return err            // без проверки res == nil, и RowsAffected ниже упадёт
}
if n, _ := res.RowsAffected(); n == 0 {
    return nil            // уже обработано → тихий 200, иначе провайдер будет ретраить вечно
}
if err := apply(ctx, tx, ev); err != nil { return err }
return tx.Commit()        // отметка и эффект коммитятся одной транзакцией

Amount int64 `json:"amount" validate:"required,gt=0,lte=100000000"`
Items  []item `json:"items"  validate:"required,min=1,max=100,dive"`

v.RegisterTagNameFunc(...)        // имена полей в ошибках - из json-тегов, а не из Go
v.RegisterValidation("slug", ...) // своё правило на поле
v.RegisterStructValidation(...)   // правило, где одно поле зависит от другого

Что стоит запомнить

• Параметры отделяют значения SQL от текста запроса; имена/направления сортировки задаются allowlist.
• SSR F возникает, когда сервер сам запрашивает адрес под контролем клиента; проверяй каждый redirect и резолв адреса.
• CSRF связан с автоматически отправляемыми браузером credentials; CORS не является механизмом авторизации.

Частые ошибки

• Не биндь request JSON прямо в доменную модель с полями is_admin/balance.
• Не считай CORS запретом для curl или серверного клиента; он управляет доступом браузерного JS к ответу.
• Не проверяй SSRF только по исходному hostname до DNS resolution: возможен DNS rebinding.

func fetchAvatar(ctx context.Context, rawURL string) ([]byte, error) {
    req, _ := http.NewRequestWithContext(ctx, http.MethodGet, rawURL, nil)
    resp, err := http.DefaultClient.Do(req)
    if err != nil { return nil, err }
    defer resp.Body.Close()
    return io.ReadAll(resp.Body)
}

type User struct {
    ID int64 json:"id"
    Email string json:"email"
    IsAdmin bool json:"is_admin"
    Balance int64 json:"balance"
}
var u User
_ = json.NewDecoder(r.Body).Decode(&u)
_ = repo.Update(ctx, &u)