Améliorer la sécurité des extensions

Améliorer la sécurité dans Manifest V3

Il s'agit de la dernière des trois sections décrivant les modifications nécessaires pour le code qui ne fait pas partie du service worker de l'extension. Il décrit les modifications requises pour améliorer la sécurité des extensions. Les deux autres sections traitent de la mise à jour de votre code nécessaire pour passer à Manifest V3 et du remplacement des requêtes Web bloquantes.

Supprimer l'exécution de chaînes arbitraires

Vous ne pouvez plus exécuter de logique externe à l'aide de executeScript(), eval() et new Function().

  • Déplacez tout code externe (JS, Wasm, CSS) dans votre bundle d'extension.
  • Mettez à jour les références de script et de style pour charger les ressources à partir du bundle d'extension.
  • Utilisez chrome.runtime.getURL() pour créer des URL de ressources au moment de l'exécution.
  • Utilisez un iFrame en bac à sable : eval et new Function(...) sont toujours compatibles avec les iFrames en bac à sable. Pour en savoir plus, consultez le guide sur les iFrames en bac à sable.

La méthode executeScript() se trouve désormais dans l'espace de noms scripting et non dans l'espace de noms tabs. Pour en savoir plus sur la mise à jour des appels, consultez Déplacer executeScript().

Il existe quelques cas particuliers dans lesquels l'exécution de chaînes arbitraires est toujours possible:

Supprimer le code hébergé à distance

Dans Manifest V3, toute la logique de votre extension doit faire partie du package d'extension. Conformément aux règles du Chrome Web Store, vous ne pouvez plus charger ni exécuter de fichiers hébergés à distance. Voici quelques exemples :

  • Fichiers JavaScript extraits du serveur du développeur.
  • Toute bibliothèque hébergée sur un CDN.
  • Des bibliothèques tierces intégrées qui récupèrent de manière dynamique le code hébergé à distance.

D'autres approches sont disponibles, en fonction de votre cas d'utilisation et du motif de l'hébergement distant. Cette section décrit les approches à envisager. Si vous rencontrez des problèmes avec le code hébergé à distance, consultez ces conseils.

Fonctionnalités et logique basées sur la configuration

Votre extension charge et met en cache une configuration distante (par exemple, un fichier JSON) au moment de l'exécution. La configuration mise en cache détermine les fonctionnalités activées.

Logique externalisée avec un service distant

Votre extension appelle un service Web distant. Cela vous permet de préserver la confidentialité de votre code et de le modifier si nécessaire, tout en évitant d'avoir à le renvoyer au Chrome Web Store.

Intégrer du code hébergé à distance dans un iFrame en bac à sable

Le code hébergé à distance est compatible avec les iFrames en bac à sable. Notez que cette approche ne fonctionne pas si le code nécessite d'accéder au DOM de la page d'intégration.

Regrouper des bibliothèques tierces

Si vous utilisez un framework populaire tel que React ou Bootstrap que vous chargiez auparavant à partir d'un serveur externe, vous pouvez télécharger les fichiers minifiés, les ajouter à votre projet et les importer localement. Exemple :

<script src="./react-dom.production.min.js"></script>
<link href="./bootstrap.min.css" rel="stylesheet">

Pour inclure une bibliothèque dans un service worker, définissez la clé "background.type" sur "module" dans le fichier manifeste et utilisez une instruction import.

Utiliser des bibliothèques externes dans les scripts injectés dans les onglets

Vous pouvez également charger des bibliothèques externes au moment de l'exécution en les ajoutant au tableau files lorsque vous appelez scripting.executeScript(). Vous pouvez toujours charger des données à distance au moment de l'exécution.

chrome.scripting.executeScript({
  target: {tabId: tab.id},
  files: ['jquery-min.js', 'content-script.js']
});

Injecter une fonction

Si vous avez besoin de plus de dynamisme, la nouvelle propriété func de scripting.executeScript() vous permet d'injecter une fonction en tant que script de contenu et de transmettre des variables à l'aide de la propriété args.

Manifest V2
let name = 'World!';
chrome.tabs.executeScript({
  code: `alert('Hello, ${name}!')`
});

Dans un fichier de script d'arrière-plan.

Manifest V3
async function getCurrentTab() {/* ... */}
let tab = await getCurrentTab();

function showAlert(givenName) {
  alert(`Hello, ${givenName}`);
}

let name = 'World';
chrome.scripting.executeScript({
  target: {tabId: tab.id},
  func: showAlert,
  args: [name],
});

Dans le service worker d'arrière-plan.

Le dépôt d'exemples d'extensions Chrome contient un exemple d'injection de fonction que vous pouvez parcourir. Vous trouverez un exemple de getCurrentTab() dans la référence de cette fonction.

Rechercher d'autres solutions

Si les approches précédentes ne vous aident pas à répondre à votre cas d'utilisation, vous devrez peut-être trouver une autre solution (par exemple, migrer vers une autre bibliothèque) ou trouver d'autres façons d'utiliser les fonctionnalités de la bibliothèque. Par exemple, dans le cas de Google Analytics, vous pouvez passer au protocole de mesure Google au lieu d'utiliser la version JavaScript officielle hébergée à distance, comme décrit dans notre guide Google Analytics 4.

Mettre à jour le règlement sur la sécurité du contenu

"content_security_policy" n'a pas été supprimé du fichier manifest.json, mais il est désormais un dictionnaire qui accepte deux propriétés: "extension_pages" et "sandbox".

Manifest V2
{
  ...
  "content_security_policy": "default-src 'self'"
  ...
}
Manifest V3
{
  ...
  "content_security_policy": {
    "extension_pages": "default-src 'self'",
    "sandbox": "..."
  }
  ...
}

extension_pages : fait référence aux contextes de votre extension, y compris aux fichiers HTML et aux service workers.

sandbox: fait référence aux pages d'extension en bac à sable utilisées par votre extension.

Supprimer les règles de sécurité du contenu non compatibles

Manifest V3 interdit certaines valeurs de Content Security Policy dans le champ "extension_pages" qui étaient autorisées dans Manifest V2. Plus précisément, Manifest V3 interdit celles qui permettent l'exécution de code à distance. Les instructions script-src,, object-src et worker-src ne peuvent avoir que les valeurs suivantes:

  • self
  • none
  • wasm-unsafe-eval
  • Extensions non empaquetées uniquement: n'importe quelle source localhost (http://localhost, http://127.0.0.1 ou n'importe quel port sur ces domaines)

Les valeurs de la règle de sécurité du contenu pour sandbox ne sont pas soumises à ces nouvelles restrictions.