Визначте межу до створення екрана
У гіпотетичному туристичному застосунку людина вводить offline maps і натискає «Пошук». Пристрій має передати цей намір бекенду, а не отримати ключ, який оплачує архівні запити. Браузерну збірку можна дослідити; поширюваний мобільний застосунок також може розкрити вбудовані рядки чи вихідні заголовки. Значення, відкрите під час збірки, не стає приватним від назви «змінна середовища».
Зберігання ключа на бекенді змінює те, що має знати випущений клієнт. Йому потрібен контракт запитів вашого застосунку, наприклад пошукова фраза та дозволена спільнота. Заголовок автентифікації архіву додає сервер. Ця архітектура все одно потребує контролю доступу й уважної експлуатації; перенесення секрету не робить увесь застосунок автоматично безпечним.
Приймайте невеликий запит застосунку
У першій версії бекенд міг би приймати фразу й номер сторінки, самостійно задаючи subreddit=hiking і limit=3. Перевіряйте довжину й діапазони та дозволяйте лише варіанти, які справді підтримує застосунок. Не приймайте від клієнта довільний хост архіву, DSL запитів чи заголовок автентифікації для пересилання. Це запропонована межа застосунку, а не додаткова кінцева точка Reddit App API.
Коли бекенд звертається до архіву, використовуйте X-API-Key або Authorization: Bearer. Неправильні параметри, відхилені до резервування кредиту, не коштують кредиту; успішні порожні відповіді коштують. Перевірка допомагає користувачам виправляти помилки й робить інтеграцію передбачуваною. Вона не доводить, що архів охоплює запитану дату або що правильний пошук поверне корисні записи.
Відокремлюйте вхід в обліковий запис
Сесійний cookie сайту сервісу з атрибутами Secure та HttpOnly дає операторові змогу керувати обліковим записом і рахунками. API-ключ автентифікує запити з вашого бекенду. Вхід мандрівника у ваш туристичний застосунок, якщо ви його реалізуєте, — ще один окремий зв’язок. Не передавайте мандрівникам cookie облікового запису сервісу й не тлумачте 401 ключа як доказ завершення їхньої сесії застосунку.
API-ключ і баланс прив’язані до окремого орендаря, тобто не є спільними для мережі доменів. Зберігайте облікові дані redditapp.com із чіткою міткою домену. Ключ іншого бренду не стане дійсним через зміну URL призначення. Спільна для мережі перевірка права на пробні кредити не об’єднує окремі баланси в один фонд.
Перевіряйте журнали як частину захисту секрету
Переносячи API-ключ на бекенд, подбайте й про його журналювання. Перевірте трасування запитів, звіти про винятки та системи спостережуваності на копіювання заголовків автентифікації. Зберігайте корисний діагностичний запис операції та статусу без вихідного ключа, пароля облікового запису чи повних секретних даних запиту.
Повертайте повідомлення, на яке мандрівник може відреагувати. Помилка ключа сервісу потребує уваги оператора, малий баланс — рішення щодо облікового запису, обмеження частоти — стриманості. Постійні повтори 401 або 402 не усувають причини. Якщо відповідь на запит втрачено, зафіксуйте невизначеність, а не припускайте безкоштовну невдачу чи підтверджений успіх.
Замінюйте ключ, не втрачаючи з поля зору розгортання
Під час реєстрації повний ключ показується один раз, до оплати. Надалі обліковий запис показує префікс, а не відновлювану копію. Оператор після входу може підтвердити пароль і згенерувати ключ заново; старий одразу стане недійсним. Підготуйте перелік середовищ бекенду для заміни й оновіть їх свідомо. Зміна одного сховища секретів не обіцяє автоматичного оновлення кожного запущеного процесу.
Надійно зберігайте пароль: поточний сервіс не має процедури його скидання або входу через Google. Після заміни перевірте змінене розгортання окремим запитом, пам’ятаючи, що успішне отримання даних оплачується. Під час переходу зберігайте чесні повідомлення завантаження й помилок. У /uk/#field-notes є пов’язані нотатки про проєктування станів і бюджет.
