Технічна реалізація перехоплення HTTP-запитів у браузерному розширенні

Технічна реалізація перехоплення 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%.

Додаткова таблиця: коли застосовувати статичні та динамічні правила

Обмеження declarativeNetRequest

Крім ліміту на кількість правил (5 000 включених), важливо пам'ятати: динамічні правила можна додавати тільки з service worker, а не з popup або content script. Також усі правила мають бути оголошені заздалегідь — не можна згенерувати правило на основі довільного JS-обчислення. Для налагодження використовуйте chrome.declarativeNetRequest.getMatchedRules() і testMatchOutcome(). Ці методи допоможуть перевірити, яке правило спрацює для конкретного URL, і виявити конфлікти.

Що входить у нашу реалізацію

• Архітектура: проєктування системи правил (статичні + динамічні) з урахуванням лімітів MV3.
• Content scripts: monkey-patching для модифікації тіла запитів, якщо необхідно.
• Налагодження: тестування правил через testMatchOutcome, логування спрацювань.
• Документація: опис усіх правил, схеми перенаправлень.
• Підтримка: супровід після запуску, оновлення при зміні API.

Процес роботи

1. Аналітика — вивчаємо структуру запитів вашого додатку, виявляємо цілі перехоплення. (1-2 дні)
2. Проєктування — створюємо специфікацію правил, погоджуємо з вами. (1 день)
3. Реалізація — пишемо код розширення, включаючи service worker і content scripts. (2-5 днів)
4. Тест — перевіряємо на реальних сценаріях, відловлюємо edge cases. (1-2 дні)
5. Деплой — публікуємо в Chrome Web Store (або корпоративний реєстр).

Строки та гарантії

Строк розробки — від 5 до 15 робочих днів залежно від складності. Орієнтовна вартість робіт — від $500 до $2000. Наприклад, одне з наших рішень дозволило клієнту заощадити $3000 на місяць на CDN-витратах. Ми гарантуємо стабільну роботу та відповідність політикам Chrome Web Store. Досвід — понад 50 проєктів з браузерних розширень.

За детальною інформацією звертайтеся до офіційної документації declarativeNetRequest. Отримайте консультацію щодо вашого проєкту — зв'яжіться з нами для обговорення.