Пожалуйста, не открывайте публичные GitHub Issue по уязвимостям. Используйте ответственное раскрытие (responsible disclosure):

Направляйте отчёт приватно на flora.dev.hub@gmail.com с темой [SECURITY].

Включите в отчёт: описание, шаги воспроизведения (proof of concept), затронутые компоненты и предполагаемое воздействие. Мы стараемся ответить в разумные сроки и согласовать дату публикации исправления. Не эксплуатируйте уязвимость на чужих данных и не публикуйте детали до выпуска фикса.

В рамках подготовки к публичному релизу закрыты release-blocking проблемы:

• Секреты: удалены из репозитория и истории; конфигурация — через gitignored-файлы и переменные окружения; в репозитории только example-шаблоны с плейсхолдерами.
• JWT: убран дефолтный секрет; fail-fast при отсутствии или слабости Jwt:Secret (минимальная длина/энтропия проверяются при старте).
• Аутентификация: enforcement 2FA (TOTP) на логине; per-account login lockout (блокировка после серии неудачных попыток); timing-safe сравнение кодов верификации (CryptographicOperations.FixedTimeEquals).
• Rate limiting: UseRateLimiter + политики на login/register/verify/refresh/account-sensitive/ write/upload; партиционирование по IP (через X-Forwarded-For) и по субъекту JWT.
• Авторизация: закрыт IDOR приватных сообществ; повторная аутентификация на удалении аккаунта; ограничен доступ к gRPC auth; ValidateToken не возвращает все claims.
• Загрузки: аватары проходят magic-byte валидацию, бюджет пикселей (anti-decompression-bomb) и переэнкод; сужены MIME-типы музыки; у ffmpeg/ffprobe — wall-clock timeout и лимиты ресурсов.
• Web: security-заголовки (CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy); NEXT_PUBLIC_DEV_AUTO_AUTH и dev-байпассы выключаются в production-сборке; DeveloperExceptionPage — только в Development.

Следующие пункты — осознанные ограничения текущей MVP-версии, а не случайные баги. Они запланированы к исправлению после релиза. Эксплуатация Flora Ecosystem в продакшене с обработкой чувствительных данных должна учитывать эти риски.

• Где: Apps/Web/lib/fscp/storage.ts.
• Суть: приватные ключи FSCP на вебе хранятся в localStorage.
• Риск: при успешной XSS-атаке ключи могут быть извлечены из браузера.
• План: перенос в неэкспортируемые CryptoKey (WebCrypto, extractable: false) / IndexedDB, усиление CSP до отказа от unsafe-inline/unsafe-eval.

• Где: Products/Flora.Social/FscpWireEnvelopeValidator.cs.
• Суть: сервер проверяет наличие и форму senderSignatureBase64Url (Ed25519, 64 байта) и ключа подписи, но не верифицирует подпись криптографически. Подпись проверяет клиент получателя при расшифровке.
• Риск: сервер не отбраковывает конверты с некорректной подписью на входе (это делает клиент).
• План: добавить серверную верификацию Ed25519 как defense-in-depth (не заменяя клиентскую).

• Суть: после расшифровки резервной копии не проверяется целостность набора эпох ключей (epochSetHash).
• Риск: теоретическая возможность подмены/усечения набора эпох в недоверенном хранилище бэкапа.
• План: проверка epochSetHash после decryption перед применением.

• Суть: refresh-токены и секреты TOTP хранятся в базе данных без дополнительного шифрования/хэша.
• Риск: при компрометации БД злоумышленник получает действующие refresh-токены и TOTP-секреты.
• План: хранить хэш refresh-токенов (как паролей) и шифровать TOTP-секреты ключом из KMS/секрета приложения.

• Суть: используется единственная bootstrap key-эпоха; отсутствует механизм ratchet и полноценный per-device UUID.
• Риск: нет forward secrecy и post-compromise security: компрометация ключа эпохи раскрывает все сообщения этой эпохи.
• План: ввести ratchet (по образцу Double Ratchet) и эпохи/устройства с ротацией ключей.

Проект находится в стадии активной разработки (MVP). Безопасностные исправления выпускаются для актуальной ветки main. Гарантий поддержки старых тегов/форков нет.

Контакт по вопросам безопасности: flora.dev.hub@gmail.com. Коммерческие лицензии и гарантии: Egor Ozerskikh / Luna Ecosystem — e.ozerskikh@gmail.com (см. LICENSE-COMMERCIAL.md).