CSP, CORS и security headers — что фронтендер обязан понимать глубже

Принято считать, что безопасность — это зона бэкенда.
Фронтенд «просто отправляет запросы и рендерит UI».

На практике фронтенд напрямую влияет на то,
будет приложение безопасным или нет.

CORS — это не про «разрешить запрос»

CORS часто воспринимают как настройку:
«чтобы запросы не падали из браузера».

Но по сути это механизм, который говорит:
кто имеет право читать ответ.

Важно понимать:

👉 сервер может обработать запрос
👉 но браузер может не дать прочитать ответ

Именно поэтому:

👉 Access-Control-Allow-Origin: * — не «фикс», а потенциальная дыра
👉 credentials + wildcard — запрещённая комбинация

CORS — это про контроль доступа, а не про обход ошибок.

CSP — ваш последний рубеж

Content Security Policy — это защита от XSS,
даже если у вас уже есть уязвимость.

Пример:

Content-Security-Policy: default-src 'self'; script-src 'self'

Что это даёт:

👉 запрещает выполнение inline-скриптов
👉 блокирует загрузку скриптов с чужих доменов
👉 режет целый класс атак

Но есть нюанс.

Если CSP выглядит так:

script-src * 'unsafe-inline' 'unsafe-eval'

Это не защита. Это иллюзия.

Security headers, которые реально важны

👉 X-Content-Type-Options: nosniff
Браузер не пытается угадать тип файла. Меньше атак через подмену.

👉 X-Frame-Options / frame-ancestors
Защита от clickjacking.

👉 Strict-Transport-Security (HSTS)
Принудительный HTTPS. Без вариантов.

👉 Referrer-Policy
Контроль того, какие данные уходят при переходах.

Где фронтендер влияет напрямую

👉 какие скрипты подключаются
👉 есть ли inline JS
👉 используются ли eval-подобные вещи
👉 как работают сторонние виджеты
👉 как обрабатываются пользовательские данные

Можно иметь идеальный бэкенд и сломать всё на уровне UI.

Частая ошибка

«Мы включили CSP — значит всё ок».

Но:

👉 нет nonce / hash
👉 разрешены любые источники
👉 подключены сторонние скрипты без контроля

В итоге защита есть только на бумаге.

Главная мысль

CSP, CORS и заголовки — это не чекбокс в настройках.
Это часть архитектуры.

Если фронтенд не понимает, как они работают,
безопасность становится случайностью.

LLM в продакшене: реальные проблемы

В демо всё выглядит магией:
модель отвечает, пишет код, общается как человек.

В продакшене начинается реальность.

И она гораздо менее глянцевая 👇

1️⃣ Галлюцинации — уверенно, но неправильно

LLM не “знает”.
Она генерирует наиболее вероятный ответ.

Поэтому:
👉 придумывает факты
👉 ссылается на несуществующие источники
👉 уверенно врёт

Самое опасное — звучит правдоподобно.

2️⃣ Нестабильность ответов

Один и тот же запрос:

👉 сегодня → один ответ
👉 завтра → другой
👉 с чуть изменённой формулировкой → третий

Для бизнеса это боль.

👉 сложно тестировать
👉 сложно гарантировать качество

3️⃣ Prompt engineering — это костыль

В теории:
«просто напиши хороший prompt»

На практике:

👉 десятки версий prompt’ов
👉 постоянный тюнинг
👉 ломается от малейших изменений

Это не инженерия. Это шаманство с контролем версий.

4️⃣ Стоимость растёт незаметно

Каждый запрос = токены = деньги

А дальше:
👉 длинные контексты
👉 RAG
👉 chain’ы
👉 retries

Прототип за $50 превращается в систему за $5000+.

5️⃣ Latency убивает UX

LLM думает долго:

👉 1–3 секунды — норм
👉 5–10 секунд — уже раздражает
👉 10+ секунд — пользователь ушёл

Особенно критично для:
👉 чатов
👉 real-time систем
👉 API

6️⃣ Evaluation — это ад

Как понять, что стало лучше?

👉 accuracy не работает
👉 метрик нет
👉 нужно вручную оценивать ответы

Evaluation = дорого + субъективно + медленно.

7️⃣ Безопасность и контроль

LLM может:
👉 сгенерировать токсичный текст
👉 выдать приватные данные
👉 обойти ограничения

Нужны:
👉 guardrails
👉 фильтры
👉 логирование
👉 мониторинг

8️⃣ Контекст — ограниченный ресурс

Даже у больших моделей:

👉 ограничение на токены
👉 длинные диалоги ломаются
👉 важная информация теряется

Поэтому без RAG никуда.

💥 Главный инсайт

LLM в продакшене — это не про модель.

Это про систему вокруг неё:
👉 retrieval
👉 кеширование
👉 monitoring
👉 fallback’и
👉 eval pipeline

В одном предложении

Сложность LLM-продукта — не в том, чтобы «подключить GPT»,
а в том, чтобы сделать его надёжным.

ROC-AUC vs PR-AUC: когда что использовать

ROC-AUC и PR-AUC — две метрики, которые постоянно путают.
И чаще всего выбирают не ту.

Разберём на пальцах 👇

📈 Что такое ROC-кривая

ROC-кривая показывает:

👉 TPR (Recall) — сколько положительных нашли
👉 FPR — сколько отрицательных ошибочно посчитали положительными

Насколько хорошо модель отделяет классы.

ROC-AUC — площадь под этой кривой.

📊 Что такое PR-кривая

PR-кривая показывает:

👉 Precision — насколько точны предсказания
👉 Recall — сколько положительных нашли

Насколько хорошо модель находит редкий класс без мусора.

PR-AUC — площадь под этой кривой.

⚔️ Главная разница

👉 ROC-AUC → разделимость классов
👉 PR-AUC → качество положительных предсказаний

🚨 Где все ошибаются

Используют ROC-AUC при сильном дисбалансе классов.

Почему это плохо?

👉 FPR считается по огромному количеству негативов
👉 даже плохая модель может выглядеть «хорошо»

ROC-AUC становится слишком оптимистичной.

📉 Когда нужен PR-AUC

Если у тебя:

👉 fraud detection
👉 churn prediction
👉 medical diagnosis
👉 rare event detection

👉 используй PR-AUC

Потому что тебе важно:

👉 находить редкий класс
👉 не засыпать всё false positive

📈 Когда подходит ROC-AUC

Если:

👉 классы более-менее сбалансированы
👉 важна общая separability
👉 задача — в целом отличать классы

👉 тогда ROC-AUC ок

🧠 Интуитивный пример

Представь:

👉 1% — мошенники
👉 99% — нормальные

Модель говорит «всё ок» почти всегда:

👉 ROC-AUC может быть высоким
👉 PR-AUC будет низким

Потому что модель не ловит мошенников.

💥 Главный инсайт

ROC-AUC отвечает на вопрос:

Модель в принципе различает классы?

PR-AUC отвечает на вопрос:

Насколько полезны её положительные предсказания?

В одном предложении

Если класс редкий — PR-AUC важнее ROC-AUC.
Если баланс нормальный — можно использовать ROC-AUC.

ML-модели становятся помощниками в принятии решений на рекламных платформах

Технический директор рекламной платформы Т-Банка Василий Разумных рассказал, как работает система, в которой модели используются не только для предсказания кликабельности. По его словам, ML-модели определяют, что показывать конкретному человеку в определенный момент времени. На смену ручной сегментации приходит ML-таргетинг: система сама находит нужную для цели аудиторию. Скоринговая модель помогает в ранжировании: она учитывает экономическую эффективность, вероятность действия и репутацию рекламодателя.

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

Ошибки при train/test split

Train/test split — кажется самой простой частью ML.
Но именно здесь чаще всего ломают всю модель.

И самое опасное — ты можешь даже не заметить

Data Leakage — тихий убийца моделей

Ты случайно «подсматриваешь» в тест.

Примеры:

👉 нормализация на всём датасете до split
👉 target encoding на всех данных
👉 feature, напрямую связанная с таргетом

Модель показывает космический скор,
а в проде — провал.

Случайный split там, где нельзя

Ты делаешь random split…
но данные зависимы.

Примеры:

👉 временные ряды
👉 пользователи (один и тот же user в train и test)
👉 сессии

Модель узнаёт данные, а не обобщает.

Игнорирование времени

В задачах с временем:

👉 ❌ случайный split
👉 ✅ train = прошлое, test = будущее

Иначе ты:

👉 обучаешься на будущем
👉 предсказываешь прошлое

Это не ML. Это читерство.

4️⃣ Дисбаланс классов в split

Ты сделал split и получил:

👉 train: 5% positive
👉 test: 1% positive

Метрики начинают врать.
Решение:

👉 stratified split

Слишком маленький test

Test = 50 объектов
Accuracy = 90%

Звучит круто.
Но это статистический шум.

Маленький test = ненадёжная оценка.

Тест используется как валидация

Классическая ошибка:

👉 обучился
👉 посмотрел на test
👉 подкрутил модель
👉 снова посмотрел

Это уже не test. Это validation 2.0.

Дубликаты в train и test

Если один и тот же объект попал в обе выборки:

Модель просто запоминает.
Особенно критично:

👉 CV
👉 e-commerce
👉 табличные данные с ID

Неправильный split в CV

Cross-validation тоже можно сломать:

👉 leakage между фолдами
👉 группы не учитываются
👉 time-series перемешаны

Используй:

👉 GroupKFold
👉 TimeSeriesSplit

Главный инсайт

Train/test split — это не про «разделить данные».

Это про симуляцию реального мира.
Если split не отражает прод —
все метрики бесполезны.

В одном предложении

Плохой split может сделать плохую модель «идеальной» —
до момента, когда она выйдет в прод.

Feature Engineering важнее выбора модели

Самый непопулярный факт в ML:
модель — это не главное.

Можно часами выбирать между:
XGBoost
LightGBM
CatBoost
…и получить +1% к качеству.

А можно поменять фичи — и получить +20%.

Разберёмся, почему так 👇

Модель учится только на том, что ты ей дал

Garbage in → garbage out

Если признаки:
- шумные
- нерелевантные
- плохо отражают задачу

👉 никакая модель не спасёт

Даже самая большая.

Пример из жизни

Задача: предсказать отток клиентов

Фичи:
- возраст
- город
- тариф

Модель: ок, но слабый результат

Добавили:
- время с последнего действия
- частоту использования
- изменение активности

👉 резкий рост качества

Почему?
Потому что фичи начали отражать реальное поведение

Feature Engineering = внедрение знаний о задаче

Модель не знает:
- бизнес
- контекст
- причинно-следственные связи

Зато ты знаешь.
И когда ты создаёшь фичи —
ты “вшиваешь” это знание в данные.

Модель vs Фичи

Что меняем → эффект

Модель → +1–5%
Гиперпараметры → +1–3%
Feature Engineering → +10–50%

Где FE особенно решает

- Табличные данные
- Маленькие датасеты
- Бизнес-задачи

👉 там, где нет миллионов примеров, фичи — это всё

Когда модель важнее
- CV (изображения)
- NLP (тексты)
- Speech

👉 там фичи учатся автоматически

Почему все игнорируют FE

Потому что:
- это сложно
- это долго
- нет “магической кнопки”
- требует понимания данных

Гораздо проще:
“давай попробуем ещё одну модель”

Главный инсайт

ML — это не соревнование моделей.
Это соревнование представлений данных.

В одном предложении

Лучший способ улучшить модель —
👉 перестать тюнить модель и начать тюнить данные

Data Leakage: как незаметно сломать модель

Самая коварная ошибка в ML — это не плохая модель.
Это data leakage.

Потому что:

👉 модель показывает идеальные метрики
👉 ты радуешься
👉 выкатываешь в прод
👉 всё разваливается

И ты не понимаешь почему.

Что такое Data Leakage

Data leakage — это ситуация, когда модель
получает доступ к информации из будущего или из target’а,
которой не будет в реальном использовании.

Модель читерит, а не учится.

Почему это так опасно

Потому что leakage:

👉 не очевиден
👉 не даёт ошибок
👉 сильно улучшает метрики

Чем лучше скор — тем подозрительнее.

Классические примеры leakage

1. Нормализация до split

Сделали scaling на всём датасете,
а потом разбили на train/test.

Модель уже «видела» test.

2. Target encoding на всех данных

Посчитали средний target по категории
используя весь датасет.

В train попала информация из test.

3. Фичи из будущего

Пример:

👉 предсказываем отток
👉 используем действия после момента предсказания

Модель знает будущее.

4. Дубликаты

Один и тот же объект:

👉 в train
👉 и в test

Модель просто запоминает.

5. Неправильный split

Временные ряды:

👉 случайный split

Модель обучается на будущем.

Как понять, что у тебя leakage

Сигналы:

👉 слишком высокий score
👉 огромный разрыв между offline и продом
👉 модель «слишком уверена»
👉 странно важные фичи

Если выглядит слишком хорошо — скорее всего, так и есть.

Как защититься

1. Делай split до любых преобразований

Сначала:
👉 train / test

Потом:
👉 scaling
👉 encoding
👉 feature engineering

2. Следи за временем

👉 train = прошлое
👉 test = будущее

3. Используй pipeline

Все трансформации:
👉 обучаются только на train
👉 применяются к test

4. Проверяй фичи

Задай вопрос:

Эта информация доступна в момент предсказания?

Если нет — удаляй.

5. Делай sanity check

👉 обучись на случайных данных
👉 убери подозрительные фичи

Если качество не падает — что-то не так.

Главный инсайт

Data leakage — это не баг.
Это иллюзия качества.

В одном предложении

Если модель слишком хороша —
сначала проверь leakage, а потом радуйся.