Обфускуйте розширення браузера перед публікацією

Опубліковане розширення є zip-архівом, який будь-хто може розпакувати й прочитати. Що змінює обфускація фонових і контентних скриптів і яку політику магазину варто перевірити, перш ніж випускати таке розширення.

Будь-хто може розпакувати опубліковане розширення і прочитати все, що в ньому є. Чи дозволено вам випускати обфусковане розширення, залежить від магазину.

Опубліковане розширення є копією вашого вихідного коду, яку можна завантажити

Опубліковане розширення є копією вашого вихідного коду, яку можна завантажити. Пакет, який роздає магазин, є zip-файлом, і щоб його розпакувати, досить одного клацання правою кнопкою. Фоновий скрипт, контентні скрипти і вся вбудована в бандл логіка стають звичайними файлами на диску. Будь-хто може прочитати найцікавіше, забрати це собі й повторно завантажити форк під іншою назвою.

Спершу перевірте політику магазину

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

Обфускація не є способом пройти перевірку чи приховати від рецензента, що робить ваше розширення. Якщо магазин запитує, що робить код, дайте відповідь на це запитання.

Що змінює обфускована збірка розширення

Там, де обфускована збірка дозволена, результат відповідає вимогам платформи. Він працює без eval, який забороняє політика безпеки контенту (CSP) розширення.

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

Запускайте його на запакованому результаті

Запустіть CLI на каталозі з результатом збірки як крок після збірки або використайте плагін AfterPack для свого бандлера, якщо його під'єднано:

$ npx afterpack@latest dist/ --preset=hard

Збираються лише файли .js, .mjs і .cjs, тож manifest.json і все в _locales/ проходить без змін. Використовуйте paths.exclude для вендорного SDK, який треба залишити як є, і paths.include, щоб дістатися до копії з node_modules/, вбудованої в пакет. Якщо ім'я символу має залишатися однаковим у ваших власних файлах, закріпіть його через identifiers.reserved.

Збирайте всі контексти за один запуск, фоновий service worker і контентні скрипти разом, щоб вони мали спільний сід, а типи повідомлень, від яких залежать обидві сторони, залишалися узгодженими.

Перевірте пакет, перш ніж архівувати його

Після збірки відкрийте Protection Map, щоб підтвердити, що скрипти, які ви хотіли захистити, покрито. Тримайте sourceMap.enabled вимкненим для пакета, який завантажуєте, бо map усередині zip дає такий самий повний доступ до вихідного коду, як і постачання оригінальних файлів. Запустіть afterpack verify на каталозі, який збираєтеся архівувати, щоб збірка, до якої захист не застосувався, завершилася помилкою ще до того, як потрапить у магазин.

Чого це не зупиняє для розширення

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

Це не заважає нікому читати, форкати чи повторно завантажувати пакет, а ключ чи токен усередині розширення не стає безпечним від того, що його закодовано. Цей випадок розглянуто в розділі Що робити з API-ключем, який доводиться постачати.

Далі