---
read_when:
    - Написание документации, включающей токены, ключи API или фрагменты учетных данных
    - Обновление примеров, которые могут сканироваться инструментами обнаружения секретов
summary: Соглашения о заполнителях, безопасных для сканера секретов, в документации и примерах
title: Соглашения о заполнителях секретов
x-i18n:
    generated_at: "2026-06-28T23:45:12Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 87e0db9ad47bf0c9d434da9bdcd6587e0b01d4eddf5ad245cf3dc87a1d166875
    source_path: reference/secret-placeholder-conventions.md
    workflow: 16
---

# Соглашения для плейсхолдеров секретов

Используйте плейсхолдеры, которые понятны человеку, но не похожи на настоящие секреты.

## Рекомендуемый стиль

- Предпочитайте описательные значения вроде `example-openai-key-not-real` или `example-discord-bot-token`.
- В фрагментах shell предпочитайте `${OPENAI_API_KEY}` вместо встроенных строк, похожих на токены.
- Оставляйте примеры очевидно ненастоящими и ограниченными назначением (провайдер, канал, тип аутентификации).

## Избегайте этих шаблонов в документации

- Буквальный текст заголовка или окончания приватного ключа PEM.
- Префиксы, похожие на действительные учетные данные, например `sk-...`, `xoxb-...`, `AKIA...`.
- Похожие на настоящие bearer-токены, скопированные из runtime-журналов.

## Пример

```bash
# Хорошо
export OPENAI_API_KEY="example-openai-key-not-real"

# Лучше (когда документ о подключении env)
export OPENAI_API_KEY="${OPENAI_API_KEY}"
```