---
title: "Générateur de hash CSP gratuit : script et style inline"
description: "Collez un script ou style inline, obtenez son hash CSP SHA-256, 384 ou 512 et la ligne script-src à coller. Supprimez unsafe-inline. Calcul 100 % local."
url: "https://centralcsp.com/fr/tools/csp-hash/"
lang: "fr"
---

Outils

# Calculateur de hash CSP

Collez un script ou un style inline et obtenez son hash pour l'autoriser dans votre Content-Security-Policy.

Contenu du script ou style inline [Comment fonctionnent les hashs CSP](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce) Le calcul du hash se fait localement dans votre navigateur via l'API Web Crypto. Rien n'est envoyé.

256 384 512

Calculer le hash

Besoin d'un hash d'intégrité pour un fichier distant ? [Utiliser le calculateur SRI](https://centralcsp.com/fr/tools/sri-hash/)

Guide

## Comprendre les hashs CSP

Ce générateur de hash CSP vous permet de conserver un script ou un style inline précis dans vos pages tout en appliquant une Content-Security-Policy stricte, sans recourir au mot-clé dangereux 'unsafe-inline'.

### Qu'est-ce qu'un hash CSP ?

Un hash CSP est un condensé SHA encodé en base64 du contenu exact d'un élément script ou style inline. Vous l'ajoutez à votre politique pour que le navigateur n'exécute que ce fragment précis et bloque tout ce qu'il n'attend pas.

Comme la valeur est dérivée du code lui-même, une politique stricte peut autoriser le code inline auquel vous faites confiance tout en bloquant tout script qu'un attaquant parviendrait à injecter dans la page. Lisez l'explication complète dans le [guide des hashs et nonces CSP](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce).

### Supprimer unsafe-inline sans casser vos scripts inline

Copiez la valeur générée, avec son préfixe sha256- et les guillemets, dans votre directive script-src pour les scripts ou style-src pour les styles. Vous pouvez lister plusieurs hashs dans la même directive.

Ne hashez que le contenu situé entre les balises, jamais les balises script ou style elles-mêmes. Le condensé doit correspondre au contenu inline octet par octet : un simple espace ou saut de ligne ajouté produit un hash différent et le navigateur le rejettera. Pour la syntaxe complète de la directive, consultez la [directive script-src](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/directives/script-src).

```
Content-Security-Policy:
  script-src 'self' 'sha256-RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc=';

# the same generated value, for an inline <style> block instead
Content-Security-Policy:
  style-src 'self' 'sha256-RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc=';
```

### Pourquoi votre hash CSP ne correspond pas

Presque toutes les non-correspondances viennent d'un octet modifié après le calcul du hash. Un moteur de template ou un minifieur a reformaté le script au build suivant ; un CDN a retiré ou ajouté des espaces dans la balise ; la valeur a été prise sur les balises plutôt que sur le contenu entre elles ; ou un éditeur a laissé un saut de ligne final que le navigateur ne perçoit pas comme vous.

Le raccourci consiste à laisser le navigateur vous le dire. Quand une politique bloque un script inline, le message de violation en console affiche la valeur sha256 calculée par le navigateur pour ce contenu exact : vous pouvez donc la copier directement depuis les DevTools au lieu de deviner quel octet a bougé.

Une règle qui piège souvent : un hash dans script-src ne couvre pas les attributs de gestionnaire d'événement inline comme onclick. Ceux-ci relèvent de script-src-attr et demandent 'unsafe-hashes', une construction plus faible qu'il vaut mieux éviter. Déplacez plutôt le gestionnaire dans le bloc script.

### SHA-256, SHA-384 ou SHA-512 ?

Content-Security-Policy accepte trois algorithmes. SHA-256 est le plus utilisé et amplement suffisant pour tout site ; SHA-384 et SHA-512 produisent des valeurs plus longues sans avantage pratique pour la CSP. Choisissez un algorithme et utilisez-le de façon cohérente dans toute votre politique.

### Hashs ou nonces ?

unsafe-inline, hash et nonces comparés
| Approche | Ce qu'il autorise | Cesse de fonctionner si le code change | Nécessite un serveur par requête |
| --- | --- | --- | --- |
| `'unsafe-inline'` | Tout script inline de la page, y compris ceux qui sont injectés | Non | Non |
| Hash | Exactement l'extrait que vous avez haché, octet par octet | Oui, et c'est bien le but | Non |
| Nonce | Tout script portant l'attribut nonce de cette requête | Non | Oui, une valeur fraîche à chaque réponse |

Lorsque vous pouvez modifier la réponse à chaque requête, préférez un nonce : il est imprévisible, à usage unique et continue de fonctionner même quand le code inline change, ce qui en fait le choix par défaut le plus robuste. N'utilisez un hash que lorsqu'un nonce n'est pas praticable, pour des fragments inline statiques ou du code tiers que vous ne pouvez pas marquer à chaque réponse. Les politiques strictes s'appuient généralement d'abord sur un nonce avec strict-dynamic et recourent aux hashs uniquement là où un nonce ne peut pas aller. Les deux mécanismes sont détaillés dans le [guide des hashs et nonces CSP](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce).

```
script-src 'self' 'nonce-2726c7f26c' 'strict-dynamic';
```

Pour aller plus loin

-   [Hashs et nonces CSP](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce)
-   [La directive script-src](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/directives/script-src)
-   [La directive style-src](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/directives/style-src)
-   [Présentation de Content-Security-Policy](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy)
-   [Générer un hash CSP (sha256) pour un script inline](https://centralcsp.com/fr/blog/csp-hash-sha256)
-   [SRI ou hash CSP : deux hash, deux usages](https://centralcsp.com/fr/blog/sri-vs-csp-hash)
-   [Mettre en place un nonce CSP à chaque requête](https://centralcsp.com/fr/blog/csp-nonce-setup)
-   [Les mots-clés CSP, dont unsafe-hashes](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/values/csp-keywords)

Plus d'outils gratuits

## Poursuivez l'audit avec les autres outils gratuits

Chaque outil est gratuit, fonctionne sans compte et note avec la même échelle de sévérité.

### Scanner CSP

Récupérez la Content-Security-Policy réellement servie par une URL et notez-la face aux contournements connus, aux sources joker et aux directives manquantes.

-   Constats au niveau des directives
-   Lien de résultats partageable

[Lancer le scanner CSP](https://centralcsp.com/fr/tools/csp-scanner/)

### Évaluateur CSP

Collez une politique pas encore déployée et obtenez la même notation et les mêmes constats qu'un scan en ligne, sans URL.

-   Auditez avant de déployer
-   Même moteur de notation

[Évaluer une politique dans l'évaluateur CSP](https://centralcsp.com/fr/tools/csp-evaluator/)

### Scanner d'en-têtes de sécurité

Notez chaque en-tête de sécurité envoyé par une URL, de HSTS à Permissions-Policy, avec chaque constat expliqué et priorisé.

-   Tous les en-têtes, une seule note
-   Correctifs classés par impact

[Scanner vos en-têtes de sécurité](https://centralcsp.com/fr/tools/security-headers/)

### Vérificateur Reporting API

Vérifiez que le signalement des violations fonctionne vraiment : les endpoints, Reporting-Endpoints et Report-To, et quelles fonctionnalités de sécurité rapportent réellement.

-   Cartographie des endpoints et fonctionnalités
-   Pertes silencieuses signalées

[Vérifier votre configuration Reporting API](https://centralcsp.com/fr/tools/reporting-api/)

### Générateur de hash SRI

Transformez l'URL d'un script ou d'un CSS servi par un CDN en hash Subresource Integrity, avec une balise prête à coller et une vérification CORS.

-   SHA-256, 384 et 512
-   CORS vérifié pour vous

[Générer un hash SRI](https://centralcsp.com/fr/tools/sri-hash/)

### Comparateur de sites

Situez votre score : votre site à côté de la moyenne du jeu de données et des sites les mieux configurés de l'année, contrôle par contrôle.

-   Références publiées et vérifiables
-   Vue radar par catégorie

[Comparez votre site aux meilleurs](https://centralcsp.com/fr/tools/compare/)

FAQ

## Questions fréquentes

Le calcul du hash, la correspondance et l'endroit où placer la valeur, expliqués.

### Faut-il inclure les balises <script> dans le hash ?

Non. Ne hachez que le contenu situé entre les balises. Le navigateur calcule son empreinte sur le contenu texte de l'élément : inclure <script> ou </script> produit une valeur qui ne correspondra jamais, et le script reste bloqué.

### Pourquoi mon hash CSP est-il toujours bloqué ?

Parce que le contenu a changé d'au moins un octet après le calcul du hash. Un minifieur ou un moteur de template a reformaté le script, un CDN a modifié les espaces, ou un éditeur a laissé un saut de ligne final. L'empreinte est exacte à l'octet près, par conception. Le plus rapide est de lire le message de violation dans la console : il affiche la valeur sha256 calculée par le navigateur pour le contenu qu'il a réellement vu.

### Un hash CSP fonctionne-t-il pour les styles inline ?

Oui. La même valeur générée se place dans style-src plutôt que dans script-src lorsque vous avez haché le contenu d'un bloc <style> inline. Le mécanisme est identique, seule la directive change.

### Peut-on lister plusieurs hash dans une même directive ?

Oui, et c'est le cas normal. Ajoutez un hash entre quotes par extrait inline à autoriser, séparés par des espaces, dans la même directive script-src ou style-src. Le navigateur autorise un extrait dont l'empreinte correspond à l'un d'eux.

### Faut-il utiliser un hash ou un nonce ?

Préférez un nonce si vous pouvez définir une valeur fraîche à chaque réponse : il continue de fonctionner quand le code inline change, ce qu'un hash ne fait délibérément pas. Utilisez un hash quand un nonce n'est pas praticable, pour des extraits inline statiques ou du code tiers que vous ne pouvez pas marquer à chaque requête. Les politiques strictes commencent en général par un nonce avec strict-dynamic et se rabattent sur des hash là où le nonce n'atteint pas.

## Votre CSP casse quelque chose ?

CentralCSP collecte de vrais rapports Content-Security-Policy depuis les navigateurs de vos visiteurs, pour repérer une politique cassée ou un script bloqué avant que cela ne vous coûte cher. Ajoutez un en-tête, sans modification de code.

[Commencer avec CentralCSP](https://app.centralcsp.com) [Transformer les hash de scripts en preuves PCI](https://centralcsp.com/fr/platform/pci-dss/)

---

Disponible en : [en](https://centralcsp.com/en/tools/csp-hash/), [fr](https://centralcsp.com/fr/tools/csp-hash/)