Вопрос #1615367

Кратко и по делу — принципы и конкретные практики для защищённой REST API, с пояснениями и примерами параметров.
1) Аутентификация
- Используйте стандарты: OAuth2 (authorization code + PKCE для SPAs/mobile), OpenID Connect для идентификации.
- Токены: короткоживущие access-токены и долгоживущие refresh-токены. Пример: access-token \(=15\ \text{min}\), refresh-token \(=30\ \text{days}\).
- Формат токенов: JWT удобен, но не храните в нём чувствительные данные; проверяйте подпись и срок годности; поддерживайте механизмы ревокации (черный список или version в базе).
- Доп. уровень: mutual TLS для внутренних сервисов или высокозащищённых клиентов.
- Хранение: клиент — secure storage (Keychain/Keystore); на сервере — хешированные секреты, минимальный доступ.
2) Авторизация
- Принцип наименьших привилегий (least privilege).
- Модели: RBAC для простоты, ABAC или ACLs для гибкости; при сложной логике — централизованный PDP (policy decision point).
- Проверяйте авторизацию на каждом конечном пункте (never trust client).
- Разграничение данных: фильтрация результатов по owner/tenant; multi-tenant — проверка tenant id в каждом запросе.
3) Защита от CSRF
- Для cookie-based аутентификации:
- Используйте SameSite=strict/lax и Secure + HttpOnly.
- CSRF-токены (synchronizer token pattern) или double-submit cookie.
- Для токен- (Bearer) авторизации в заголовке \("Authorization: Bearer ..."\) CSRF риск минимален; всё же защищайте формы и state-changing endpoints.
- CORS: явно указывайте origin, не ставьте wildcard для Credentials; проверяйте preflight-запросы.
4) Защита от XXE
- Отключайте внешние сущности и DTD в XML-парсерах: конфиг по умолчанию должен быть "secure".
- Предпочитайте JSON; если XML необходим — используйте безопасные парсеры/библиотеки и валидацию схем.
- Примитив: для XML-парсера установить внешние сущности = false.
5) Защита от SQL-инъекций
- Всегда используйте параметризованные запросы / prepared statements.
- ORM + прямые запросы: избегайте конкатенации строк; если нужно — применяйте строгую валидацию и escaping.
- Паттерн доступа к БД через слой репозитория; минимальные привилегии у учетной записи БД.
- Валидация типов и длины входа, белые списки для полей типа sort/column.
6) Лимитирование (rate limiting) и защита от DDoS
- Реализуйте на уровне API gateway / edge (NGINX, Envoy, Cloud provider).
- Полезные политики: per-user, per-IP, per-endpoint; комбинируйте.
- Примеры: мягкий лимит \(100\ \text{req/min/user}\) с burst до \(200\), жесткий — \(1000\ \text{req/min/ip}\).
- Алгоритмы: token bucket / leaky bucket для burst-поддержки.
- Реакции: заголовок Retry-After, правильный HTTP статус (\(429\)).
- Защита от brute-force: блокировка после \(5\) неудачных попыток на \(15\ \text{min}\) или progressive delays.
7) Логирование и мониторинг
- Логируйте: timestamp, request id, user id, endpoint, response code, latency, source IP, reason for failure. Не логируйте пароли/PII.
- Централизованный сбор: ELK/EFK, SIEM, alerts при аномалиях.
- Хранение: политика ретеншена и шифрование логов. Пример: ретеншн \(=90\ \text{days}\) для детальных логов, агрегаты дольше.
- Аудит: отдельные журналы для критичных операций (изменение прав, вывод средств).
- Маскирование: маскируйте/токенизируйте чувствительные поля.
8) Баланс безопасности и удобства
- Безопасность по умолчанию + опции для developer experience:
- Документация + SDK/CLI, примеры аутентификации.
- Разумные таймауты: очень короткие токены усиливают безопасность, но увеличивают UX; решайте через refresh flow.
- Graceful errors: информативные, но не раскрывающие внутренностей (например, не возвращать "user exists" vs "invalid credentials" однозначно).
- Системы для разработчика: sandbox/whitelist для тестовых ключей с расширенными лимитами.
- Прогрессивное усиление: применяйте риск-основанные проверки (MFA) только при подозрительной активности, чтобы не мешать обычным пользователям.
- Автоматизация: CI/CD проверяет безопасность-код (SAST/DAST), линтеры для SQL/XXE-паттернов.
9) Архитектурные принципы и практики
- Defense in depth: несколько слоёв защиты (gateway, приложение, БД).
- Fail securely: при ошибках — ограничивайте доступ, не «открывайте».
- Least privilege everywhere: сервисы, БД, ключи.
- Контроль версий и быстрый откат: ability to revoke keys/tokens rolling.
- Threat modeling и регулярные pentest/bug-bounty.
Короткая чек-листа (важнейшее):
- Аутентификация: OAuth2/PKCE, короткие access-токены (\(15\ \text{min}\)), refresh-token механизм.
- Авторизация: проверка на каждом запросе, RBAC/ABAC.
- Input: параметризованные запросы + белые списки.
- XML: отключить external entities.
- CSRF: SameSite + CSRF-токены для cookie flows.
- Rate-limits: per-user/IP с заголовком Retry-After, примеры \(100\ \text{req/min}\).
- Логи: централизовано, без PII, ретеншн \(90\ \text{days}\).
- UX: понятная документация, sandbox, риск-ориентированное усиление (MFA при подозрениях).
Если нужно — могу дать пример конфигурации rate-limiter/NGINX, схему JWT/refresh flow или список конкретных HTTP-заголовков и ответов.