MedTracker обрабатывает идентификаторы пациентов, адреса, телефоны, симптомы, геопозицию и фотографии доступа. Рассматривайте эти данные как чувствительные и применяйте требования вашей юрисдикции и организации.

• Никогда не коммитьте .env, дампы, token URLs или production-логи.
• Генерируйте разные случайные значения для каждого SEED_*, POSTGRES_PASSWORD и POSTGRES_APP_PASSWORD в каждом окружении.
• Для паролей, включаемых Compose в URL, используйте URL-safe алфавит, например hex.
• В production передавайте secrets из secret manager/orchestrator, ограничивайте доступ deploy-пользователем и ведите audit чтения.
• Пароль владельца PostgreSQL нужен только сервису миграций. Backend runtime не должен его получать.
• Изменение SEED_* после bootstrap не меняет пароль существующего аккаунта. Используйте утверждённую процедуру смены/восстановления аккаунта.
• Смена POSTGRES_* в .env не обновляет пользователей существующего PostgreSQL volume автоматически. Ротацию роли, connection URL и restart выполняйте как одну протестированную операцию.

• Завершайте TLS на контролируемом reverse proxy/load balancer; production cookie имеет флаг Secure.
• Публикуйте только frontend. Backend и PostgreSQL должны оставаться во внутренних сетях.
• Ограничьте ingress firewall-ом, а административный доступ — VPN/bastion и MFA инфраструктуры.
• Укажите точные HTTPS-origins в CORS_ORIGIN; wildcard недопустим с credentials.
• TRUST_PROXY должен соответствовать реальной цепочке. Edge proxy обязан перезаписывать/очищать входящие X-Forwarded-*, иначе IP-based rate limiting можно обойти.
• Сохраняйте WebSocket upgrade и разумные timeouts на всех proxy.

URL-токен даёт доступ без логина и равнозначен временному паролю.

• передавайте ссылку только предполагаемому получателю;
• не помещайте её в аналитику, Referer, screenshots, QR-коды общего доступа или support tickets;
• не раскрывайте полный URL в proxy/application logs;
• при ошибочной отправке или подозрении на копирование немедленно ротируйте ссылку;
• используйте короткие TTL, соответствующие рабочему процессу;
• завершение/отмена вызова должно немедленно закрывать пациентский доступ.

То же правило относится к legacy URL фотографий и compatibility API с bearer в path. Bundled Nginx отключает локальный access log для этих маршрутов, но внешний TLS/edge proxy, CDN, WAF и APM должны независимо редактировать path до записи. Новые клиенты получают данные и фото через fixed-path авторизованный POST, а фото показывают через локальный Blob URL.

В ранних версиях отслеживаемый Git файл server/db/orders_store.json содержал исторические данные временных ссылок пациента и водителя. Файл удаляется из текущего дерева и игнорируется, а runtime хранит хэши и ротирует ссылки, но обычное удаление файла не удаляет blob из истории Git, существующих клонов, forks, CI caches или backups.

До production:

1. считайте все исторические ссылки скомпрометированными и отзовите/ротируйте их;
2. определите владельца и окно переписывания истории;
3. выполните purge специализированным инструментом только после backup и согласования, затем force-update защищённых refs;
4. уведомите владельцев клонов о необходимости fresh clone и удалите старые CI artifacts/caches согласно политике;
5. проверьте mirrors, forks и backup, после чего задокументируйте incident и результат ротации.

Не копируйте найденные значения в issue, commit message, chat или runbook. Само переписывание истории без отзыва ссылок не устраняет риск.

• Собирайте только необходимые поля и ограничивайте доступ ролью и tenant scope.
• PostgreSQL RLS — дополнительный барьер, а не замена серверной авторизации и тестам изоляции.
• Не логируйте тела API/Socket.IO, координаты, симптомы, access info, фото или credentials.
• Шифруйте backup и ограничивайте доступ к photo volume так же, как к БД.
• Утвердите retention и процедуру удаления; истечение ссылки не является удалением данных.
• Перед передачей адреса/координат внешнему provider оформите правовое основание и договорные условия. Map tiles идут через backend proxy, чтобы не связывать район вызова с IP конечного пользователя, но provider всё равно видит запрошенные координаты тайлов. Сами пути z/x/y позволяют восстановить район вызова: bundled Nginx их не логирует, browser получает no-store, а edge/CDN/WAF/APM должны применять ту же редакцию.
• Кнопка внешней навигации — отдельная явная передача координат выбранному картографическому приложению. Зафиксируйте разрешённый provider и доведите это поведение до бригад.

• CI должен проходить перед merge: npm ci, backend check/tests, frontend typecheck/build и docker compose config.
• Регулярно анализируйте npm и container vulnerabilities, обновляйте Node/PostgreSQL/Nginx и проверяйте breaking changes.
• Сохраняйте CSP/security headers Nginx и проверяйте их после добавления внешних доменов. Не ослабляйте CSP широкими * или unsafe-eval.
• Проверяйте все REST и Socket.IO payload на сервере; TypeScript-типы клиента не являются runtime-защитой.
• Для загрузок ограничивайте размер, MIME и magic bytes; храните их вне web root под непрогнозируемым именем.
• Simulation должна оставаться выключенной в production.

В репозитории нет сервера автоматической SMS/WhatsApp-рассылки. wa.me открывается в браузере сотрудника и не даёт гарантии отправки, доставки или принадлежности номера. Если добавляется WhatsApp Business/SMS provider:

• проведите отдельный security/privacy review и DPA;
• храните API keys только в secret manager;
• проверяйте webhook signatures, replay protection и idempotency;
• не включайте лишние медицинские данные в сообщение;
• задайте retention для delivery logs и отказоустойчивый fallback.

Не создавайте публичный issue с эксплуатационными деталями или реальными данными. Передайте отчёт владельцу deployment по закрытому каналу, указав версию, влияние, минимальные шаги воспроизведения и безопасные тестовые данные. До публикации исправления согласуйте disclosure и ротацию затронутых секретов.