Améliorer la sécurité des extensions

Améliorer la sécurité dans Manifest V3

Remarque:Manifest V3 est généralement compatible avec Chrome 88 ou version ultérieure. Pour en savoir plus sur les fonctionnalités d'extension ajoutées dans les versions ultérieures de Chrome, consultez la documentation de référence de l'API. Si votre extension nécessite une API spécifique, vous pouvez spécifier une version minimale de Chrome dans le fichier manifeste.

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 plutôt que dans l'espace de noms tabs. Pour en savoir plus sur la mise à jour des appels, consultez Déplacer executeScript().

Dans certains cas particuliers, l'exécution de chaînes arbitraires est toujours possible:

• Injecter des feuilles de style hébergées à distance dans une page Web à l'aide d'insertCSS
• Pour les extensions qui utilisent chrome.devtools: inspectWindow.eval permet d'exécuter du code JavaScript dans le contexte de la page inspectée.
• Les extensions de débogueur peuvent utiliser chrome.debugger.sendCommand pour exécuter du code JavaScript dans une cible de débogage.

Supprimer le code hébergé à distance

Dans Manifest V3, toute la logique de votre extension doit faire partie du package d'extension. Conformément au Règlement 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.
• Bibliothèques tierces groupées qui récupèrent de manière dynamique du code hébergé à distance.

D'autres approches sont disponibles, en fonction de votre cas d'utilisation et du motif de l'hébergement à distance. Cette section décrit les approches à envisager. Si vous rencontrez des problèmes avec le code hébergé à distance, consultez nos 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. Vous pouvez ainsi conserver le code privé et le modifier si nécessaire, tout en évitant les frais supplémentaires liés à une nouvelle soumission sur le 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.

Attention:Certaines bibliothèques (Firebase, par exemple) récupèrent du code supplémentaire si nécessaire au moment de l'exécution. Pour éviter cela, deux options s'offrent à vous. Vous pouvez choisir une bibliothèque qui n'utilise pas de code hébergé à distance. Vous pouvez également télécharger toutes les importations dynamiques possibles au moment de la compilation. Voici un exemple de script qui regroupe Firebase à l'aide de Rollup.js.

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 en 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 de fond.

Le dépôt d'exemples d'extensions Chrome contient un exemple d'injection de fonction que vous pouvez suivre. Un exemple de getCurrentTab() se trouve dans la documentation de cette fonction.

Rechercher d'autres solutions

Si les approches précédentes ne vous aident pas dans 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 la stratégie de sécurité du contenu

"content_security_policy" n'a pas été supprimé du fichier manifest.json, mais il s'agit désormais d'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.

Remarque:Ces types de pages sont diffusés à partir du protocole chrome-extension://. Par exemple, une page de votre extension est chrome-extension://EXTENSION_ID/foo.html.

sandbox: fait référence à toutes les pages d'extension en bac à sable que votre extension utilise.

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

Le fichier manifeste V3 interdit certaines valeurs de règles de sécurité du contenu dans le champ "extension_pages" qui étaient autorisées dans le fichier manifeste V2. Plus précisément, Manifest V3 interdit celles qui permettent l'exécution de code à distance. Les directives script-src,, object-src et worker-src ne peuvent avoir que les valeurs suivantes:

• self
• none
• wasm-unsafe-eval
• Extensions non décompressées uniquement: toute source localhost (http://localhost, http://127.0.0.1 ou tout port de ces domaines)

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