Безопасность для аналитика: что нельзя светить
↑ 1.3 Аутентификация и безопасность API · ← Предыдущая
Зачем это аналитику и PM
Пример для бага и постановки легко уносит боевой токен, пароль и живого клиента. Секрет в чате живёт дольше задачи, а персональные данные в учебном JSON становятся утечкой, даже если «это всего лишь скрин».
План темы
- токены и ключи в скриншотах и чатах
- персональные данные в примерах
- тестовые и боевые данные
Объяснение
Секрет аналитика — всё, чем можно войти, прочитать чужое или доказать, что запись принадлежит живому человеку. В работу с API такое попадает само: заголовок, cookie, адрес, тело ответа, выгрузка. Задача — чтобы пример оставался проверяемым и при этом был безвредным.
Как черновик договора. Номер счёта и паспорт закрывают плашкой, смысл пункта оставляют. Читатель понимает поле, но не может уйти с документом в банк. Плашка *** в заметке работает так же.
Токены, ключи, скрины
Не публикуют значение Authorization, cookie сессии, API-ключ, пароль Basic, секрет клиента, refresh-токен и строку JWT целиком. Скрин вкладки сети часто показывает их в одном кадре с адресом. Перед отправкой в чат или тикет кадр обрезают либо замазывают значение. В тексте оставляют имя заголовка и маску: Bearer eyJ... или ***.
Ссылка с ключом в query тоже секрет: её копируют из строки браузера не глядя. Если так устроен чужой API, в баг кладут путь без значения параметра. После случайной отправки секрет считают засвеченным. Его гасят и выпускают новый, Кого звать для гашения, знает владелец стенда.
Персональные данные
В примерах не используют живые ФИО, телефоны, почту, адреса, номера документов и платежные следы клиентов. Учебные значения берут вымышленные: user-example, ada@example.com. Домен example.com для этого и зарезервирован. Выгрузка с боя, даже «пара строк для реализма», в общую папку команды не кладётся. Если без похожих данных дефект не поймать, это решает безопасность, не автор кейса.
Тест и бой
Тестовый ключ не проверяет на боевом хосте. Боевой ключ не хранят в коллекции, которой пользуется весь канал. Одинаковый секрет на двух стендах превращает учебный скрин в доступ к клиентам. В отчёте о баге пишут хост стенда и маску секрета, не сам секрет. Персональные данные на тесте иногда всё же оказываются копией боя. Тогда с ними обращаются как с боевыми, даже если в адресе есть слово test.
| Что увидели | Что оставить в примере | Что убрать |
|---|---|---|
| Заголовок допуска | Имя заголовка и *** | Значение целиком |
| Адрес с ключом | Путь и имена параметров | Значения секретов |
| Тело с клиентом | Имена полей и типы | Живые контакты и документы |
| Ключ стенда | Имя стенда | Сам ключ и перенос на другой хост |
Примеры
Плохой фрагмент и чем его заменить. Оба текста вымышлены, но левый уже похож на то, что нельзя пересылать.
плохо: Authorization: Bearer eyJhbGciOi.real-looking.payload
лучше: Authorization: Bearer eyJ...{
"id": "user-example",
"email": "ada@example.com",
"role": "analyst"
}Нюансы и подводные камни
- Удалить сообщение не значит забрать секрет назад. Его всё равно меняют.
- Запись HAR и экспорт коллекции тащат заголовки целиком. Перед передачей файла его открывают и ищут слово Authorization.
- Общий тестовый пользователь с паролем в вики — тоже секрет. Пароль уносят в хранилище, в странице оставляют имя учётки.
Практика
Возьмите последний скрин или curl из своей переписки с разработчиком и вычеркните всё, чем можно войти или узнать живого клиента.
Ожидаемый результат: в тексте остались метод, путь, код ответа и имена полей. Значения допуска заменены на ***. Живых контактов нет. Если секрет уже ушёл в чат, рядом записано, кого просите его погасить, а не фраза «потом удалю сообщение».
Вопросы с ответами
Почему нельзя приложить JWT целиком?
По строке можно ходить в API, пока она не протухла и её не отозвали. Подпись не прячет утверждения внутри. В тикете хватает маски и расшифровки нужного claim без самой подписи.
Тестовый ключ можно послать в боевой хост?
Нет. Так вы либо ударите по живым данным, либо смешаете секреты стендов. Хост и секрет берут парой из документации одного окружения.
Что делать, если ключ уже в скрине?
Сообщить владельцу стенда, чтобы секрет погасили и выпустили новый. Стереть только своё сообщение недостаточно: копии уже могли разойтись.