# « The Content Security Policy directive upgrade-insecure-requests is ignored when delivered in a report-only policy » : que signifie cet avertissement ?

> Chrome affiche cet avertissement quand upgrade-insecure-requests figure dans un en-tête Content-Security-Policy-Report-Only. Rien n’est cassé. Voici pourquoi la directive ne peut pas fonctionner en report-only et où la placer.

- Canonical: https://info.centralcsp.com/fr/articles/csp-upgrade-insecure-requests-ignored-report-only/
- Published: 2026-08-09
- Language: fr
- Publisher: CentralCSP (https://centralcsp.com)

Vous avez déployé un en-tête `Content-Security-Policy-Report-Only`, ouvert la console, et Chrome vous a accueilli avec :

> The Content Security Policy directive 'upgrade-insecure-requests' is ignored when delivered in a report-only policy.

La version courte : rien n’est cassé, aucune requête n’échoue, et le reste de votre politique est bien évalué. Le navigateur vous prévient que cette directive précise ne peut rien faire depuis un en-tête report-only, alors il l’a sautée. La correction consiste à déplacer `upgrade-insecure-requests` dans un en-tête `Content-Security-Policy` appliqué, sa vraie place.

Maintenant la version longue, parce que la raison mérite d’être comprise.

## Pourquoi le navigateur l’ignore

La plupart des directives CSP sont des restrictions. `script-src`, `img-src`, `frame-ancestors` : elles décrivent ce que la page a le droit de faire, et le navigateur sait les évaluer selon deux modes. Le mode appliqué bloque la violation. Le mode report-only la laisse passer et envoie un rapport. Observer sans intervenir, c’est précisément ce qui rend le report-only sûr en production.

`upgrade-insecure-requests` n’est pas une restriction. C’est une action. Elle demande au navigateur de réécrire chaque requête de sous-ressource non sécurisée (`http://example.com/logo.png`) en HTTPS avant même son départ. Or il n’existe aucun moyen d’« observer » une réécriture sans la faire. Une politique report-only qui modifierait vos requêtes trahirait le contrat même du mode report-only. La spécification prévoit donc que la directive y soit simplement ignorée, et Chromium vous le dit.

Même logique pour `sandbox`, au passage : elle agit sur la page au lieu de restreindre des chargements, et elle est ignorée elle aussi dans les politiques report-only.

## La correction : deux en-têtes, une ligne chacun

Vous n’avez pas à choisir entre tester votre politique et réécrire vos requêtes. HTTP autorise les deux en-têtes CSP en même temps, et ils fonctionnent indépendamment :

```http
Content-Security-Policy: upgrade-insecure-requests
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-to csp-endpoint
```

Le premier en-tête applique exactement une chose : la réécriture. C’est à peu près la directive appliquée la moins risquée qui soit, puisque son seul effet est de transformer des URL `http://` en `https://` sur un site que vous servez déjà en HTTPS. Si une ressource n’existe pas en HTTPS, les navigateurs modernes l’auraient de toute façon bloquée comme contenu mixte.

Le second en-tête garde votre vraie politique en observation : les violations sont rapportées, rien n’est bloqué. Le jour du passage en mode strict, la directive rejoint simplement l’en-tête principal avec le reste.

MDN documente exactement ce schéma, et c’est ce que nous recommandons à chaque équipe en plein [déploiement report-only](/fr/articles/build-vs-buy-csp-report-collector/) : appliquer tout de suite les directives sûres et peu coûteuses, observer les risquées.

## Et pour trouver les requêtes non sécurisées elles-mêmes ?

La directive de réécriture masque le problème autant qu’elle le corrige : les URL `http://` sont toujours dans votre HTML, votre CSS, vos templates. Les navigateurs les rattrapent au moment de la requête, mais le jour où quelqu’un ouvre la page dans un vieux client, ou copie une URL ailleurs, l’insécurité refait surface.

Pour les trouver réellement, gardez dans votre en-tête report-only une politique qui restreint les sources à `https:`. Chaque URL non sécurisée produit alors un rapport de violation avec l’URL du document et la ressource fautive, autrement dit une liste de corrections pour vos templates. Une plateforme de reporting comme [CentralCSP](https://centralcsp.com) agrège ces rapports par origine pour corriger en masse plutôt qu’avertissement par avertissement. Le [scanner](https://centralcsp.com/fr/tools/csp-scanner/) repère d’ailleurs les directives mal placées comme celle-ci avant qu’un navigateur n’ait à vous prévenir.

## La checklist

1. Sortez `upgrade-insecure-requests` de `Content-Security-Policy-Report-Only`.
2. Ajoutez-la à un en-tête `Content-Security-Policy` appliqué (seule, c’est très bien).
3. Gardez aussi `Strict-Transport-Security` : les deux résolvent des problèmes différents.
4. En option, conservez `default-src https:` dans votre politique report-only pour inventorier les références `http://` restantes dans votre code.

L’avertissement disparaît, les réécritures ont réellement lieu, et votre déploiement report-only continue sans être touché. Pour le détail du comportement de chaque directive, la [référence upgrade-insecure-requests](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/directives/upgrade-insecure-requests) couvre tout, y compris les cas de navigation volontairement laissés de côté.

## Questions fréquentes

### Cet avertissement casse-t-il mon site ?

Non. Le navigateur signale qu’une directive de votre politique report-only n’a aucun effet. Toutes les autres directives continuent d’être évaluées et de générer des rapports de violation. L’avertissement est purement informatif.

### Puis-je tester upgrade-insecure-requests sans appliquer toute ma politique ?

Oui. Envoyez deux en-têtes en même temps : une Content-Security-Policy appliquée contenant uniquement upgrade-insecure-requests et votre politique complète en Content-Security-Policy-Report-Only. Les deux coexistent, la réécriture a lieu réellement, et le reste de votre politique reste en observation.

### upgrade-insecure-requests remplace-t-il HSTS ?

Non. upgrade-insecure-requests réécrit les requêtes de sous-ressources des pages que vous servez. Strict-Transport-Security fait en sorte que le navigateur atteigne tout votre site en HTTPS dès le départ. Un site en production doit utiliser les deux.

### Firefox et Safari affichent-ils le même avertissement ?

La formulation exacte vient de Chromium, vous la verrez donc dans Chrome et Edge. Le comportement est en revanche identique partout : aucun navigateur n’applique upgrade-insecure-requests depuis un en-tête report-only, ce mode ne modifiant jamais les requêtes.