---
read_when:
    - Написання документації, що містить токени, ключі API або фрагменти облікових даних
    - Оновлення прикладів, які можуть скануватися засобами виявлення секретів
summary: Безпечні для сканерів секретів правила використання заповнювачів у документації та прикладах
title: Умовні позначення заповнювачів секретів
x-i18n:
    generated_at: "2026-07-12T13:46:24Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 0864f0fcc6fb1e4a3147b4b2ce0aac475437a19d694f3d059374782428c7f248
    source_path: reference/secret-placeholder-conventions.md
    workflow: 16
---

# Правила використання заповнювачів для секретів

Використовуйте зрозумілі людині заповнювачі, які не схожі на справжні секрети.

## Рекомендований стиль

- Надавайте перевагу описовим значенням, як-от `example-openai-key-not-real` або `example-discord-bot-token`.
- У фрагментах команд оболонки надавайте перевагу `${OPENAI_API_KEY}` замість вбудованих рядків, схожих на токени.
- Приклади мають бути очевидно несправжніми та відповідати своєму призначенню (постачальник, канал, тип автентифікації).

## Уникайте цих шаблонів у документації

- Буквального тексту заголовка або завершального рядка приватного ключа PEM.
- Префіксів, схожих на справжні облікові дані, наприклад `sk-...`, `xoxb-...`, `AKIA...`.
- Реалістичних токенів-носіїв, скопійованих із журналів середовища виконання.

## Приклад

```bash
# Добре
export OPENAI_API_KEY="example-openai-key-not-real"

# Краще (коли документація стосується налаштування змінних середовища)
export OPENAI_API_KEY="${OPENAI_API_KEY}"
```