Токен, заменяющий конфиденциальное значение, и токен, предоставляющий доступ, выполняют разные задачи. Область использования и серверные проверки прав остаются определяющими.
Замена значения не устраняет все риски
Токенизация заменяет конфиденциальное значение. Системы бывают обратимыми и необратимыми, с хранилищем соответствий или без него. Токен может сохранять возможность сопоставления или разрешённых операций, поэтому его кража не обязательно безвредна. Псевдонимизация не равна анонимизации: при выполнении условий GDPR данные остаются персональными.
Защищать канал и проверять каждую операцию
TLS защищает трафик между своими конечными точками, но не исправляет ошибки авторизации или взломанный сервер. Подписанный JWT не обязательно зашифрован: его содержимое может читаться. Проверять подпись, издателя, получателя и действительность согласно протоколу, затем права на объект. Для OAuth использовать RFC 9700 и определить срок действия, отзыв и защиту от повторного использования с учётом архитектуры.
Три механизма и границы их защиты
| Механизм | Назначение | Что проверить |
|---|---|---|
| Токенизация данных | Заменить конфиденциальное значение. | Соответствие, повторная идентификация и возможности токена. |
| Шифрование | Защитить конфиденциальность с помощью ключей. | Управление ключами и раскрытие после расшифрования. |
| Токен доступа | Предъявить разрешение сервису. | Украденный bearer-токен можно использовать повторно; проверять права на сервере. |
Источники и границы применимости
- PCI SSC · Tokenization Product Security Guidelines · 2015 · pp. 6–8
- IETF · RFC 7519 · JSON Web Token · 2015
- IETF · RFC 9700 · OAuth 2.0 Security BCP · 2025
- EUR-Lex · GDPR / RGPD · Art. 4(5), recital 26
Редакционная проверка: 31 октября 2026 года.
Не путайте защищенные данные с авторизованными действиями.
Шифрование и токенизация снижают риск утечки данных, но не определяют, может ли вызов API считывать объект или запускать операцию. OWASP относит авторизацию на уровне объектов и функций к основным рискам API.
- Проверяйте разрешения для каждого запрашиваемого объекта и действия, даже за аутентифицированным шлюзом.
- Тестируйте запросы между учетными записями и ролями с использованием демонстрационных данных.
- Сохраняйте записи, готовые к расследованию, без регистрации секретов или конфиденциальных значений в открытом текстовом виде.
Первичный источник: OWASP API Security Top 10 — 2023. Связанный метод: прочитать практическое руководство.
Passkey: подготовить смену домена и RP ID
Разделить учётную запись, веб-источник и RP ID, чтобы не переназначать данные входа скрытно.
- Запишите старые и новые источники, RP ID и связанные записи. Одинаковое имя записи не делает passkey действительным для другого RP ID. Проверьте допустимые сочетания WebAuthn и доступные пути входа на переходе.
- В разрешённой тестовой среде проверьте challenge, источник, RP ID и связь с записью подходящей библиотекой. Испытайте неожиданный источник и повтор challenge. Смена RP ID требует новой аутентифицированной регистрации: копирование строки не переносит ключ.
- Проверьте пользователя только со старым credential, восстановление и открытые сессии. Задайте открытие и закрытие путей с проверенным возвратом. Регистрация на новом домене не доказывает отзыв всех старых сессий.
Воспроизводимый приёмочный случай
Вымышленный пример: данные не описывают клиента или наблюдаемый результат.
Посмотреть данные случая
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}Ожидаемое решение
Вымышленный пример: запись та же, но old.example меняется на new.example с другим RP ID. Старый credential нельзя скрытно перепривязать; новая регистрация проходит предусмотренный аутентифицированный путь.
Можно ли изменить RP ID passkey редактированием базы?
Нет. RP ID входит в проверяемую область credential. Подготовьте допустимую новую регистрацию и аутентифицированную связь записи.
Первичный источник: W3C — Web Authentication Level 2. Связанный метод: прочитать практическое руководство.
Продление TLS: проверить реально выдаваемый сертификат
Проследить продление до точек завершения TLS и клиентов перед закрытием изменения.
- Перечислите имена, CDN, балансировщики, прокси и внутренние соединения с сертификатами. Запишите выдаваемый сертификат, цепочку, срок и ответственного. Выпуск не доказывает установку на всех узлах. Защитите закрытые ключи, не включайте их в реестр.
- Проверьте автоматизацию в тестовой среде поставщика, если она есть. Проверьте задания валидации, имена SAN, защищённое хранение и перезагрузку компонентов. Не выпускайте при каждом запуске, если есть пригодный сертификат по политике ключей.
- Проверьте имена, даты и цепочку доверия поддерживаемыми клиентами по нужным путям. Не отключайте проверку TLS. Следите за сроком выдаваемого сертификата, не только планировщиком. Откат требует действующего сертификата и не скомпрометированного ключа; иначе исправьте или изолируйте точку.
Воспроизводимый приёмочный случай
Вымышленный пример: данные не описывают клиента или наблюдаемый результат.
Посмотреть данные случая
{
"issuance_succeeded": true,
"proxy_count": 2,
"proxies_serving_expected_certificate": 1,
"other_proxy_certificate_expired": true,
"tls_verification_enabled": true,
"expected": "change_incomplete_fix_and_verify_client_paths"
}Ожидаемое решение
Вымышленный пример: продление успешно, но один из двух прокси выдаёт просроченный сертификат. Изменение не завершено; исправьте прокси и проверьте клиентские пути, не отключая TLS.
Первичный источник: Let’s Encrypt — Integration Guide. Связанный метод: прочитать практическое руководство.
Источники: данные, применение и ограничения
Документация проверена .
Подробные справочные заметки в этой версии доступны на английском.
| Источник и назначение | Проверенные данные или ориентир | Как использовать | Сохраняемое ограничение |
|---|---|---|---|
| MITRE · Common Weakness Enumeration Name classes of software and hardware weakness. |
A CWE describes a weakness that can contribute to vulnerabilities. It does not represent a particular incident. | Connect the weakness to the observed mechanism: input, processing and missing control. Use it to fix the cause and plan regression tests. | A keyword in a report alone does not establish the correct CWE classification. |
| OASIS · TAXII 2.1 Exchange threat intelligence through an application protocol. |
TAXII 2.1 is an OASIS Standard dated 10 June 2021. It includes service discovery and access to collections. | Test authentication, collection permissions, pagination and recovery after interruption. Record which objects were actually received and processed. | TAXII transports data; it replaces neither the content model nor assessment of reliability. |
Обзор каталога CISA KEV
Подробные справочные заметки в этой версии доступны на английском.
One identifier can span several technical layers
An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.
- Connect the CVE, component supplier and final-product supplier.
- Check version, configuration and execution path in the authorised environment.
- Do not infer remediation from an empty search result.
CISA KEV · 2026.11.06 · Documentary review : 2026-11-07
Носители: очистка и доказательства
Подробные справочные заметки в этой версии доступны на английском.
Encryption and erasure require different evidence
Encryption protects access while keys and implementation retain their properties. Cryptographic erase requires suitable encrypted scope and sanitization of relevant keys; it does not follow from API-token removal.
- Map data-encryption, wrapping and derivation keys and external copies.
- Check whether target sensitive data previously existed in plaintext.
- Record technical outcome, limits and validation without retaining secrets in the evidence.
Read the methods, evidence points and annotated situations →
NIST · SP 800-88 Rev. 2 · Guidelines for Media Sanitization · Final · 2025-09-26 · consulted 2026-10-23