# Безопасность данных BloomLoop

Клиент доверяет платформе **контактные** (телефон, имя, адрес получателя) и
**платёжные (банковские)** данные. Их защита — обязательное требование на всех
уровнях, не «фича на потом». Этот документ — правила, которым обязан следовать
любой код проекта (фронтенд, бэкенд, ИИ-консультант).

## 0. Главный принцип статуса прототипа

Текущий прототип — **статический фронтенд без бэкенда**. Поэтому он:

- **НЕ собирает и НЕ передаёт реальные платёжные данные.** Оплата в прототипе —
  имитация (никаких полей карты, никакого PAN/CVV).
- **НЕ хранит реальные персональные данные.** Вход — демо-код, поля адреса/телефона
  в sell-flow никуда не отправляются.

Реальные данные появятся **только вместе с защищённым бэкендом**, построенным по
правилам ниже. До тех пор собирать настоящие реквизиты в прототипе запрещено.

## 1. Платёжные (банковские) данные

- **Мы не храним номера карт, CVV и срок действия. Никогда.** Карточные данные
  вводятся в поля **PCI DSS-сертифицированного провайдера** (эквайер / СБП) —
  через его iframe/SDK, минуя наш фронтенд и наш бэкенд. Нам возвращается только
  **платёжный токен**.
- Это сводит наш PCI-скоуп к **SAQ A**: мы оперируем токенами, не данными карт.
- **CVV не хранится никогда** (запрещено стандартом). Токены и `payment_intent`
  хранятся на стороне провайдера; у нас — только ссылки на них.
- **Эскроу** (заморозка средств покупателя до подтверждения получения букета)
  реализуется через лицензированного платёжного партнёра, а не самописно.
- Платёжные данные **никогда не попадают в логи, аналитику, историю чата
  ИИ-консультанта или память агента**.

## 2. Контактные и персональные данные (ПДн)

- **Минимизация:** собираем только необходимое (на входе — лишь телефон; имя,
  адрес, карта — по мере надобности).
- **Шифрование:** в транзите — TLS 1.2+ и HSTS; в покое (at rest) — AES-256,
  телефоны/адреса в зашифрованном виде.
- **Приватность получателя:** адрес и контакты получателя **не раскрываются
  продавцу** (доставка организуется платформой). Соответствует бизнес-доку.
- **Доступ по ролям (RBAC)** и журналирование доступа к ПДн.
- **Локализация и комплаенс:** ПДн граждан РФ хранятся на серверах в РФ
  (152-ФЗ); для ЕС — GDPR. Явное согласие на обработку, право на экспорт и
  удаление данных.

## 3. Аутентификация и доступ

- Вход по номеру телефона + одноразовый код (OTP/SMS). **Rate-limiting** на отправку
  и проверку кода, защита от перебора и enumeration, ограниченное время жизни OTP.
- Сессии с коротким TTL, безопасные `HttpOnly`/`Secure`/`SameSite` cookie или
  ротация токенов; защита от CSRF.

## 4. Секреты

- **Никаких ключей и токенов в репозитории и во фронтенде** (Яндекс.Карты,
  эквайринг, Anthropic/Claude для ИИ-консультанта). Только секрет-менеджер /
  переменные окружения вне git; регулярная ротация.
- `.env*` и артефакты проверок — в `.gitignore`.

## 5. Защита приложения

- **Транспорт:** HTTPS везде + HSTS; никакого обмена данными по HTTP.
- **XSS:** любой пользовательский ввод экранируется перед вставкой в DOM
  (в прототипе — функция `esc()` в `app.js`/`concierge.js`); в продакшене —
  строгая **Content-Security-Policy**, отказ от inline-обработчиков.
- **SQLi:** только параметризованные запросы / ORM на бэкенде.
- **Валидация на бэкенде:** клиентская валидация не доверяется; всё проверяется на
  сервере.
- **Логи:** не логировать ПДн, платёжные данные, CVV, OTP.

## 6. ИИ-консультант

- Память агента и история чата **не содержат** платёжных данных и паролей
  (см. [docs/ai-concierge.md](docs/ai-concierge.md)). Адреса получателей — под
  защитой приватности. Ключ Claude — только на бэкенде.

## Сообщить об уязвимости

Найденную проблему безопасности направляйте владельцу проекта приватно (не через
публичные issue). Подробности канала — у владельца.