Коротка відповідь
Host permissions надають доступ до сайтів для конкретних привілейованих операцій; це не універсальний список URL для всього застосунку. У Manifest V3 використовуйте host_permissions або optional_host_permissions. Місця ін’єкції контентних скриптів оголошуйте окремо в content_scripts.matches. Додайте дозвіл API для операції, наприклад scripting для програмної ін’єкції. Доступ до сайту не замінює дозвіл API.
Найчастіше пропускають різницю в обсязі шляху. Шаблон контентного скрипта може обмежувати його запуск, але шлях у host permission ігнорується. https://example.com/reports/* не обмежує привілейований доступ звітами. Якщо функція має працювати лише там, перевіряйте шлях також у коді. Ця стаття пояснює обсяг і контексти виконання; пов’язаний посібник дозволів розглядає ширший перелік функцій.
Практичні кроки реалізації
Розділіть цільову сторінку та зовнішній сервіс
Для умовного помічника звітів визначте дві межі: сторінку вибору звіту та API метаданих. Доступ до сторінки не означає доступу до origin API. Перелічуйте перенаправлення та origin стилів або ресурсів лише для реальних потреб функції. Не використовуйте всі сайти як скорочення замість пошуку відомої адреси сервісу.
Вибирайте шаблони свідомо
Віддавайте перевагу https://api.example.com/*, коли вистачає одного host. https://*.example.com/* охоплює ширшу родину піддоменів, а *:// — HTTP і HTTPS. Поточна документація Chrome також описує явні порти в шаблонах; для старіших цілей перевірте підтримку. Зберігайте перелік відповідних і невідповідних URL, зокрема оманливий api.example.com.attacker.invalid, поруч із перевіркою маніфесту.
Виконуйте запити в правильному контексті
Міжoriginний fetch контентного скрипта залишається обмеженим origin сторінки, навіть коли розширення має host permissions. Worker або сторінка розширення можуть виконувати дозволені запити. Якщо worker працює для контентного скрипта, дайте вузьку операцію lookupReport(id) замість fetchAnything(url). Перевіряйте відправника, ідентифікатор і результат; повертайте лише потрібні поля.
Передбачте недоступність як звичайний стан
Використовуйте тимчасовий activeTab для ручної перевірки, якщо тривалість підходить. Для постійної поведінки запитуйте вузький необов’язковий доступ. Перевіряйте дозволи перед роботою та обробляйте помилки навіть після успішної перевірки: користувач може відкликати доступ або вкладка змінить сторінку. Внутрішні сторінки браузера, файли та incognito мають додаткові обмеження або керування; широкі шаблони їх не усувають.
Приклад реалізації
Цей навчальний маніфест надає worker доступ до одного сервісу та окремо оголошує вузький шлях статичної ін’єкції на іншому сайті. Поля відповідають різним операціям. Host сервісу умовний; приклад не описує маніфест продукту з портфоліо.
{
"manifest_version": 3,
"name": "Report helper",
"version": "1.0.0",
"host_permissions": ["https://api.example.com/*"],
"background": { "service_worker": "worker.js" },
"content_scripts": [{
"matches": ["https://app.example.com/reports/*"],
"js": ["report-content.js"]
}]
}
Host permission надає браузерний доступ, але не автентифікацію чи авторизацію сервера. API має перевірити право користувача на звіт. Контентний скрипт не повинен відображати результат як виконуваний HTML. Якщо CSP розширення визначає connect-src, він також має дозволяти потрібний запит API.
Компроміси та альтернативи
Статична ін’єкція корисна для автоматичної функції на відомому шляху. Програмна — для вибраного моменту чи цілі, потребуючи scripting і доступу до документа. Динамічна реєстрація дає варіант для постійно дозволених сайтів, але її життєвий цикл слід узгоджувати з дозволами. Вибирайте за часом роботи та сайтами, а не довжиною фрагмента.
Опис Font Picker у репозиторії вказує можливе завантаження використаних сторінкою таблиць стилів для пошуку джерел шрифтів. Це причина відрізняти DOM-перевірку від мережевих запитів. Опис не доводить конкретного дозволу. Перевірте пакет, перш ніж вирішувати, які тимчасові, сервісні чи runtime-дозволи відповідають поведінці продукту.
Поширені помилки
- Сприйняття шляху host permission як гарантованої межі даних.
- Очікування доступу до документа лише від дозволу API.
- Перенесення fetch у контентний скрипт з очікуванням привілеїв worker.
- Дозвіл повідомленню сторінки вибирати довільний URL привілейованого fetch.
- Плутання доступу до host з авторизацією користувача на сервері.
Контрольний список перед випуском
- Кожен origin має причину, пов’язану з функцією.
- Перевірено URL зі збігом і без нього.
- Обмеження шляхів реалізовано там, де функція від них залежить.
- Мережеву поведінку скрипта й worker перевірено окремо.
- Відкликання та переходи дають видимий стан недоступності.
- Запити й відповіді мають вузький контракт повідомлень.
Поширені запитання
Чи host_permissions автоматично ін’єктує скрипт?
Ні. Ін’єкцію визначають статичні збіги, динамічна реєстрація чи явний виклик scripting. Доступ до сайту — частина дозволу на операцію, а не запит виконувати код скрізь, де він застосовний.
Чи вузький шлях URL обмежує привілейований fetch?
Не через host_permissions. Перевіряйте endpoint, метод та формат ідентифікатора у worker. Не передавайте повні URL з менш довірених контекстів лише через збіг початкового рядка.
Чому доступ зникає після надання?
Користувач може змінити доступ, тимчасовий дозвіл завершитися, документ перейти. Перевірте поточну ціль і дозвіл замість нескінченних повторів. Просіть новий доступ через зрозумілу взаємодію, коли він потрібен функції.
Висновок
Складіть окремі списки цілей ін’єкції та origin привілейованих запитів. Перевірте схему, host, контекст і дозвіл API кожної операції. Важливе обмеження шляху реалізуйте у валідації самої операції, не покладаючись на host-шаблон.
Первинні джерела
- Chrome: шаблони збігів
- Chrome: запити між origin
- Chrome: API scripting
- Chrome: дозволи під час виконання
Пов’язані посібники та приклади
Потрібно реалізувати це у вашому продукті?
Перегляньте відповідні приклади продуктів або поділіться контекстом розробки вебзастосунку, розширення Chrome, API чи SaaS.