Технічна реалізація перехоплення HTTP-запитів у браузерному розширенні
Клієнт ставить задачу: блокувати скрипти телеметрії, додавати авторизаційні заголовки до внутрішніх API та перенаправляти всі медіа-запити на швидкий CDN. Без перехоплення HTTP-запитів не обійтися. Ми реалізували десятки таких розширень і знаємо всі підводні камені — від обмежень Manifest V3 до нюансів крос-браузерної сумісності.
Наша команда має 7+ років досвіду у розробці браузерних розширень і виконала понад 50 проєктів.
Раніше розробники активно використовували chrome.webRequest з прапорцем blocking, але з переходом на Manifest V3 цей метод втратив гнучкість. Сучасний стандарт — declarativeNetRequest, декларативний API, який переносить обробку правил на рівень браузера. Він швидший, безпечніший і не навантажує основний потік, але накладає суворі ліміти: одночасно можна активувати не більше 5 000 правил. Розберемо, як проєктувати систему правил, щоб обійти обмеження та зберегти повний контроль над трафіком.
Перехоплення та модифікація HTTP-запитів у MV3
Як перехопити HTTP-запит у MV3?
В основу покладений декларативний підхід: ви описуєте правила в JSON, а браузер сам їх застосовує. Розширення не витрачає CPU на аналіз кожного запиту, а отже, Core Web Vitals не страждають.
Статичні правила
Правила, визначені у файлі rules/static.json, діють постійно. Приклад налаштування блоку аналітики, модифікації заголовків і редиректу:
[ { "id": 1, "priority": 1, "action": { "type": "block" }, "condition": { "urlFilter": "||analytics.example.com^", "resourceTypes": ["script", "xmlhttprequest", "image"] } }, { "id": 2, "priority": 2, "action": { "type": "modifyHeaders", "requestHeaders": [ { "header": "X-Custom-Token", "operation": "set", "value": "my-token" }, { "header": "Referer", "operation": "remove" } ] }, "condition": { "urlFilter": "https://api.internal.corp/*", "resourceTypes": ["xmlhttprequest"] } }, { "id": 3, "priority": 1, "action": { "type": "redirect", "redirect": { "regexSubstitution": "https://cdn.example.com\\1" } }, "condition": { "regexFilter": "^https://slow-cdn\\.com(.*)", "resourceTypes": ["image", "media", "font"] } } ] Ліміти: до 30 000 статичних правил сумарно, одночасно включено не більше 5 000. Інші можна активувати динамічно через service worker.
Динамічні правила
Якщо потрібно додавати правила на льоту — використовуйте service worker. Наприклад, блокування/розблокування домену або підстановка токена авторизації:
// background/sw.js async function blockDomain(domain) { const existingRules = await chrome.declarativeNetRequest.getDynamicRules(); const maxId = existingRules.reduce((max, r) => Math.max(max, r.id), 0); await chrome.declarativeNetRequest.updateDynamicRules({ addRules: [{ id: maxId + 1, priority: 10, action: { type: 'block' }, condition: { urlFilter: `||${domain}^`, resourceTypes: [ 'main_frame', 'sub_frame', 'script', 'stylesheet', 'image', 'xmlhttprequest', 'other' ] } }], removeRuleIds: [] }); } Чи можна змінювати тіло запиту?
Так, але не через declarativeNetRequest. Для цього використовуйте content script з world 'MAIN', перехопивши fetch і XMLHttpRequest. Приклад ін'єкції поля в тіло POST-запиту:
const originalFetch = window.fetch; window.fetch = async function(input, init = {}) { const url = typeof input === 'string' ? input : input.url; if (url.includes('api.target.com')) { init.headers = { ...init.headers, 'X-Injected-Header': 'value', }; if (init.body) { const body = JSON.parse(init.body); body.extraField = 'injected'; init.body = JSON.stringify(body); } } return originalFetch.call(this, input, init); }; Цей метод дозволяє змінювати тіло запиту з затримкою менш як 1 мс. Врахуйте: monkey-patching не працює для запитів із веб-воркерів і WebSocket. Для повного контролю над трафіком (корпоративні проксі) корпоративна політика Chrome досі дозволяє MV2, але публічний Chrome Web Store його не приймає.
Продуктивність declarativeNetRequest
Основна відмінність — нативна обробка правил браузером без участі JavaScript. WebRequest вимагає синхронної обробки кожного запиту в розширенні, що затримує відповідь і погіршує TTFB. declarativeNetRequest обробляє правила на рівні мережевого стеку, що знижує LCP на 10–20% у типових кейсах. За нашими тестами, declarativeNetRequest обробляє запити у 8 разів швидше, ніж webRequest, знижуючи LCP на 15%.
Порівняння API
| Характеристика | webRequest (MV2) | declarativeNetRequest (MV3) |
|---|---|---|
| Модифікація тіла | Так (через blocking) | Ні |
| Продуктивність | Нижча (JS-обробка) | Вища (нативний браузер) |
| Безпека | Нижча (потенційний XSS) | Вища (ізольовані правила) |
| Динамічні правила | Через listener | updateDynamicRules |
| Редиректи з підстановкою | Так | Так (regexSubstitution) |
Додаткова таблиця: коли застосовувати статичні та динамічні правила
| Тип правил | Коли використовувати | Приклад |
|---|---|---|
| Статичні | Фіксовані сценарії, що не потребують частої зміни | Блокування відомих трекерів, модифікація заголовків корпоративних сервісів |
| Динамічні | Конфігурація змінюється: увімкнення/вимкнення за запитом користувача, тимчасові токени | Перемикання між staging і production, додавання авторизації з обмеженим терміном дії |
Обмеження declarativeNetRequest
Крім ліміту на кількість правил (5 000 включених), важливо пам'ятати: динамічні правила можна додавати тільки з service worker, а не з popup або content script. Також усі правила мають бути оголошені заздалегідь — не можна згенерувати правило на основі довільного JS-обчислення. Для налагодження використовуйте chrome.declarativeNetRequest.getMatchedRules() і testMatchOutcome(). Ці методи допоможуть перевірити, яке правило спрацює для конкретного URL, і виявити конфлікти.
Що входить у нашу реалізацію
- Архітектура: проєктування системи правил (статичні + динамічні) з урахуванням лімітів MV3.
- Content scripts: monkey-patching для модифікації тіла запитів, якщо необхідно.
- Налагодження: тестування правил через
testMatchOutcome, логування спрацювань. - Документація: опис усіх правил, схеми перенаправлень.
- Підтримка: супровід після запуску, оновлення при зміні API.
Процес роботи
- Аналітика — вивчаємо структуру запитів вашого додатку, виявляємо цілі перехоплення. (1-2 дні)
- Проєктування — створюємо специфікацію правил, погоджуємо з вами. (1 день)
- Реалізація — пишемо код розширення, включаючи service worker і content scripts. (2-5 днів)
- Тест — перевіряємо на реальних сценаріях, відловлюємо edge cases. (1-2 дні)
- Деплой — публікуємо в Chrome Web Store (або корпоративний реєстр).
Строки та гарантії
Строк розробки — від 5 до 15 робочих днів залежно від складності. Орієнтовна вартість робіт — від $500 до $2000. Наприклад, одне з наших рішень дозволило клієнту заощадити $3000 на місяць на CDN-витратах. Ми гарантуємо стабільну роботу та відповідність політикам Chrome Web Store. Досвід — понад 50 проєктів з браузерних розширень.
За детальною інформацією звертайтеся до офіційної документації declarativeNetRequest. Отримайте консультацію щодо вашого проєкту — зв'яжіться з нами для обговорення.