Amélioration de 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 expliquent comment mettre à jour le code nécessaire pour passer à Manifest V3 et remplacer les requêtes Web bloquées.
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 le code externe (JS, Wasm, CSS) vers votre pack d'extensions.
- Mettez à jour les références de script et de style pour charger les ressources à partir du bundle d'extensions.
- Utilisez
chrome.runtime.getURL()
pour créer des URL de ressource au moment de l'exécution. - Utilisez un iFrame en bac à sable:
eval
etnew Function(...)
sont toujours acceptés. Pour en savoir plus, consultez le guide sur les iFrames en bac à sable.
La méthode executeScript()
se trouve maintenant dans l'espace de noms scripting
et non plus dans l'espace de noms tabs
. Pour savoir comment mettre à jour les appels, consultez Déplacer executeScript()
.
Il existe quelques cas particuliers dans lesquels l'exécution de chaînes arbitraires est toujours possible:
- Injecter des feuilles de style hébergées à distance dans une page Web avec insertCSS
- Pour les extensions utilisant
chrome.devtools
: inspectWindow.eval permet d'exécuter JavaScript dans le contexte de la page inspectée. - Les extensions du débogueur peuvent utiliser chrome.debugger.sendCommand pour exécuter 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, selon votre cas d'utilisation et le motif de l'hébergement à distance. Cette section décrit les approches à envisager. Si vous rencontrez des problèmes pour gérer du code hébergé à distance, cliquez ici pour consulter nos conseils.
Fonctionnalités et logique basées sur la configuration
Votre extension charge et met en cache une configuration à distance (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 les frais supplémentaires liés à un renvoi vers 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 l'accès au DOM de la page d'intégration.
Regrouper des bibliothèques tierces
Si vous utilisez un framework connu, tel que React ou Bootstrap, que vous avez précédemment chargé depuis un serveur externe, vous pouvez télécharger les fichiers réduits, 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 des scripts injectés par onglet
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
dans 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
.
let name = 'World!'; chrome.tabs.executeScript({ code: `alert('Hello, ${name}!')` });
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], });
Le dépôt d'exemples d'extensions Chrome contient un exemple d'injection de fonctions que vous pouvez consulter. La référence de cette fonction contient un exemple de getCurrentTab()
.
Rechercher d'autres solutions
Si les approches précédentes ne vous aident pas à résoudre 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 de 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 Content Security Policy
"content_security_policy"
n'a pas été supprimé du fichier manifest.json
, mais il s'agit désormais d'un dictionnaire qui prend en charge deux propriétés: "extension_pages"
et "sandbox"
.
{ ... "content_security_policy": "default-src 'self'" ... }
{ ... "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 de l'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 règles de sécurité du contenu dans le champ "extension_pages"
qui étaient autorisées dans Manifest V2. Plus précisément, Manifest V3 n'autorise pas celles qui autorisent 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 des règles de sécurité du contenu pour sandbox
ne comportent pas de nouvelles restrictions.