Дозволи розширень Chrome: принцип найменших привілеїв

Коротка відповідь

Вибирайте дозволи розширення Chrome за операцією, документом і моментом, коли потрібен доступ. Інструмент перевірки після натискання часто потребує activeTab і scripting; йому не обов’язково потрібні tabs або постійний доступ до всіх сайтів. Панель лише з налаштуваннями може потребувати storage без доступу до сторінок. Автоматична обробка визначених сайтів потребує іншої моделі, ніж інструмент, який користувач запускає явно.

Принцип найменших привілеїв — це перевірка можливостей, а не змагання за найкоротший маніфест. Вилучення необхідного дозволу спричиняє відмови; запит доступу для гіпотетичних функцій розширює ризик. Почніть із найменшої робочої функції та обґрунтуйте кожну додаткову можливість. Chrome розрізняє дозволи API, доступ до сайтів, шаблони контентних скриптів та їхні необов’язкові відповідники в посібнику оголошення дозволів.

Зіставте функції з можливостями

Корисний документ перевірки має окремий рядок для кожної видимої операції. Для інспектора типографіки розділіть вибір тексту, читання обчислених стилів, локальне збереження колекції та пошук джерел шрифту. Це різні межі. Читання вибраного елемента відбувається в документі; збереження налаштувань — у сховищі розширення; пошук зовнішньої таблиці стилів може потребувати мережевого запиту. Рядок «перевірка шрифтів» приховує ці відмінності.

Запишіть взаємодію запуску, контекст виконання, точний API, дозволений сайт або документ, збережені дані та поведінку за відсутності доступу. Додайте файл, який реалізує операцію. Якщо ніхто не може знайти чинний виклик для можливості, вилучіть її з кандидата на випуск і перевірте відповідні сценарії. Коментар «може знадобитися пізніше» не доводить теперішню потребу.

Опис Font Picker у портфоліо показує цю різницю: вибраний користувачем текст, локальна колекція та можливе завантаження таблиць стилів, які вже використовує сторінка. Це перелік функцій, а не підтвердження точного маніфесту пакета. Перевірте випуск, перш ніж приписувати продукту конкретні дозволи. Native Color Picker описує нативний вибір пікселя екрана й локальні палітри; дослідження DOM було б окремою функцією з окремим обґрунтуванням.

Практичні кроки реалізації

1. Розділіть доступ до API та сайту

Дозвіл API надає конкретну можливість браузера. Дозвіл доступу до сайту визначає сайти для операцій, що залежать від такого доступу. Це різні питання. Наприклад, scripting дозволяє використовувати API ін’єкції, але цільовому документу потрібен відповідний постійний чи тимчасовий доступ. Сам scripting не дозволяє ін’єкцію в довільні вкладки. Так само дозволений origin не надає всіх дозволів API для операції.

Не додавайте tabs лише через виклик chrome.tabs.query. Перевірте використані властивості й методи. Створення або пошук вкладок і читання чутливих метаданих — різні операції. Дотримуйтеся вимог API замість припущення, що простір імен має один універсальний дозвіл. Довідник дозволів пов’язує іменовані дозволи з можливостями та попередженнями.

2. Для епізодичної перевірки використовуйте явний запуск

Для одноразового дослідження сторінки розгляньте activeTab. Запуск action надає тимчасовий доступ, пов’язаний з origin головного фрейму вкладки. Він зберігається під час переходів у межах того самого origin і завершується після переходу на інший origin або закриття вкладки. Обмежені сторінки браузера залишаються недоступними. Це відповідає обіцянці «перевірити після натискання», а не «безперервно стежити за всіма сторінками». Chrome описує життєвий цикл у посібнику activeTab.

Взаємодія має значення. Таймер, автоматичне завдання панелі або повідомлення довільного сайту не замінюють дозволеного запуску користувачем. Тримайте точку входу біля action, команди або іншої підтримуваної дії. Пояснюйте недоступні сторінки в інтерфейсі. Людина має бачити «Цю сторінку браузера неможливо перевірити», а не нескінченний індикатор чи пораду розширити доступ, яка все одно не допоможе.

3. Просіть постійний доступ, коли він дає користь

Якщо користувач хоче функцію під час майбутніх відвідувань, запитуйте відповідний сайт через необов’язкові дозволи. Розділіть негайну перевірку та «завжди вмикати на цьому сайті». Друге — тривалий вибір, який потребує зрозумілого формулювання. Для відомих сайтів використовуйте конкретну схему й hostname. Якщо підтримуються довільні сайти, широке необов’язкове оголошення дозволяє вузькі запити під час виконання; оголошена межа та наданий набір — різні речі.

Відмова — звичайний результат. Залиште необов’язкову функцію вимкненою, збережіть інші налаштування та дозвольте повторити запит тим самим елементом керування. Не запитуйте доступ під час кожного відкриття панелі. Дайте можливість відкликання й перевіряйте фактичний дозвіл перед привілейованою роботою. API дозволів має request, contains, remove і події змін для цього життєвого циклу.

4. Простежте дані, які створює можливість

Дозволи обмежують доступ, але не пояснюють зберігання. Інспектор може нічого не завантажувати на сервер і все ж зберігати чутливі фрагменти локально. Визначте, чи потрібні повний текст, URL із параметрами, знімок екрана або лише обчислена властивість. Діагностичні повідомлення мають бути вужчими за досліджувані дані. Наприклад, записуйте операцію й категорію помилки замість вмісту сторінки чи адреси з даними автентифікації.

Привілейовані результати повинні мати схему. Worker повертає лише необхідні інтерфейсу поля. Контентний скрипт не має перетворювати об’єкт сторінки на довільні виклики браузерних API. Вужчі дозволи зменшують наслідки помилки валідації, але не замінюють її. Перевіряйте доступ і потік даних разом, особливо коли необов’язкова інтеграція передає результат зовнішньому сервісу.

5. Порівняйте маніфест пакета перед випуском

Інструменти збирання можуть об’єднувати маніфести, додавати типові значення чи включати варіант для розробки. Перевірте маніфест ZIP, який плануєте завантажити. Порівняйте масиви дозволів, шаблони сайтів, збіги контентних скриптів і зовнішні точки доступу з попереднім випуском. Дослідіть кожне розширення. Збережіть причину поруч зі зміною функції, щоб наступний рецензент відрізнив свідоме рішення від застарілого стартового налаштування.

Розпаковане встановлення для розробки не доводить поведінку оновлення для наявних користувачів. Використовуйте окремий профіль для перевірки дозволів і попереджень; перевірте користувачів, які відмовили або обмежили доступ до сайтів. Це рекомендовані перевірки, а не звіт про виконаний тут тест. Рекомендації щодо попереджень допомагають оцінити видимі наслідки зміни маніфесту.

Приклад реалізації

Цей мінімальний приклад читає довжину вибраного тексту після натискання action. Він не зберігає текст, не звертається до сервера й не описує реалізацію розширення з портфоліо. Ін’єктована функція самодостатня, бо виконується в документі, не зберігаючи лексичного контексту worker.

{
  "manifest_version": 3,
  "name": "Selection length inspector",
  "version": "1.0.0",
  "permissions": ["activeTab", "scripting"],
  "background": { "service_worker": "worker.js" },
  "action": { "default_title": "Inspect selection length" }
}

chrome.action.onClicked.addListener(async (tab) => {
  if (typeof tab.id !== "number") return;
  try {
    const results = await chrome.scripting.executeScript({
      target: { tabId: tab.id },
      func: () => window.getSelection()?.toString().length ?? 0,
    });
    const length = results[0]?.result;
    console.info("Selection length:", typeof length === "number" ? length : 0);
  } catch {
    console.info("Selection inspection is unavailable for this document.");
  }
});

У маніфесті свідомо немає popup: action із default_popup використовує потік панелі замість цього слухача натискання. Реальний інтерфейс має видимо показувати результат і недоступність. Якщо перетворюєте приклад на popup, реалізуйте власну взаємодію та обробку результатів замість очікування, що цей слухач також запуститься.

Типова ціль — головний фрейм. Перевірка виділення в iframe з іншим origin є окремою вимогою та може потребувати незалежного дозволу. Не змінюйте allFrames лише заради усунення скарги: визначте фрейм цілі й необхідний доступ. Довідник scripting описує цілі ін’єкції та результати.

Компроміси та альтернативи

Тимчасовий і постійний доступ

Тимчасовий доступ легко пояснити для епізодичної перевірки; він обмежує час роботи розширення. Він не забезпечує автоматичну поведінку під час майбутніх відвідувань. Постійний доступ відповідає такій поведінці, але розширює можливості скомпрометованого розширення. Вибирайте за часом роботи функції: ручний інспектор і постійний помічник можуть мати схожі екрани та різні моделі дозволів.

Обов’язкові й необов’язкові можливості

Необхідний основній функції дозвіл може належати до обов’язкових. Необов’язковий доступ корисний, коли решта продукту працює без нього. Перенесення всього в необов’язкові дозволи може створити кілька запитів і складні часткові стани перед першою корисною дією. Групуйте запити за зрозумілою функцією, не об’єднуйте непов’язані можливості та пояснюйте наслідок надання доступу.

Можливість браузера й дослідження документа

Нативна взаємодія може вирішити потребу без DOM-доступу. Описаний вибір пікселя в Native Color Picker корисно порівняти з отриманням кольорів обчислених стилів. Друге дає іншу інформацію, але не має додаватися лише через назву інструмента. Дозволи випливають із реалізації та обіцяного результату, а не категорії продукту.

Поширені помилки

Копіювання tabs, <all_urls> чи webRequest зі стартового проєкту без знайденого виклику.
Припущення, що менше попереджень доводить відсутність чутливих можливостей.
Сприйняття оголошених необов’язкових сайтів як уже наданого доступу.
Запит доступу після сторонньої асинхронної роботи замість потрібної взаємодії.
Довіра до збереженого permissionGranted після зміни налаштувань браузера.
Розширення шаблонів для виправлення доступу до обмеженої сторінки браузера.
Запис повних даних сторінки в діагностику при описі продукту як невеликого локального інструмента.

Контрольний список перед випуском

Кожна можливість маніфесту пов’язана з чинною функцією та викликом.
Ручна перевірка використовує тимчасовий доступ, коли його життєвий цикл відповідає обіцянці.
Постійний доступ має пояснення, стан відмови та відкликання.
Поведінка фреймів, обмежених сторінок, файлів та incognito визначена.
Привілейовані повідомлення й результати мають вузькі схеми виконання.
Документація розрізняє налаштування й зібрані дані сторінок.
Маніфест ZIP порівняно з попередньою версією.
Попередження встановлення та оновлення перевірено в окремому профілі.

Поширені запитання

Чи потрібен панелі дозвіл tabs?

Не просто для існування. Запитайте, що вона читає або змінює. Локальні налаштування можуть працювати без сайту; інспектору потрібен доступ до його цілі. Назва поверхні інтерфейсу не визначає дозволів. Не додавайте tabs, доки конкретна операція його не потребує.

Чи замінює activeTab усі дозволи сайтів?

Лише для функцій, сумісних із тимчасовим доступом після явного запуску. Фонова обробка невідвіданих сайтів, постійна автоматична ін’єкція та запити до сторонніх сервісів мають інші вимоги. Проєктуйте їх окремо й не обіцяйте роботу після завершення доступу.

Чи нешкідливий дозвіл без попередження встановлення?

Ні. Попередження — інтерфейс згоди, а не повна модель загроз. Оцініть дані API, недовірені входи та зберігання результатів. Перевіряйте текст попереджень разом із реалізацією. Відсутність попереджень не виправдовує неточних заяв про приватність.

Що робити після відкликання доступу?

Зупиніть майбутні привілейовані операції, оновіть стан функції та залиште інші функції доступними. Визначте, чи прибирати вже ін’єктований інтерфейс і видаляти збережені дані; це окремі дії. Повторно перевіряйте дозвіл перед операцією та обробляйте відкликання під час роботи.

Висновок

Виберіть маніфест за картою функцій і можливостей, потім перевірте пакет. Вирішальні питання: хто запускає доступ, який документ чи сервіс доступний, скільки триває дозвіл і які дані залишаються. Якщо функція не пояснює ці чотири відповіді, уточніть її межі перед додаванням дозволів.

Первинні джерела

Пов’язані посібники та приклади

Ігор Харчишин

Незалежний full-stack інженер продуктів, який пише посібники з реалізації розширень браузера та сучасних вебпродуктів на основі першоджерел.

GITHUB ↗LINKEDIN ↗

Як працюють дозволи доступу до сайтів у Manifest V3 →Необов’язкові дозволи для кращої приватності розширень →Як написати політику приватності розширення Chrome →

Потрібно реалізувати це у вашому продукті?

Перегляньте відповідні приклади продуктів або поділіться контекстом розробки вебзастосунку, розширення Chrome, API чи SaaS.

Переглянути приклади продуктів Обговорити розробку продукту