Content Security Policy en Next.js: corriger Supabase, Analytics et images externes

Une Content Security Policy trop large ne protege pas grand-chose. Une CSP trop stricte casse vite votre site. C'est exactement ce qui arrive souvent avec Next.js quand on branche Supabase, un outil analytics, des images externes ou quelques scripts utiles.

Le but d'une bonne CSP n'est pas de tout bloquer aveuglement. Le but est d'autoriser seulement les origines necessaires, rien de plus.

Pourquoi la CSP casse souvent un projet web

Quand on ajoute une CSP, on bloque par defaut certains chargements :

• scripts externes
• styles inline ou externes
• images distantes
• connexions vers des APIs
• iframes ou ressources embarquees

Du coup, des briques legitimes cessent de marcher :

• connexion Supabase
• telemetrie ou analytics
• images Open Graph ou images CDN
• widgets ou composants embarques

Le bon reflexe n'est pas de supprimer la CSP. Le bon reflexe est de comprendre quelle directive bloque quoi.

Ce que Next.js recommande

La documentation Next.js rappelle qu'une CSP sert a se proteger contre les XSS, le clickjacking et d'autres injections. Elle explique aussi deux approches :

• une CSP configuree dans next.config.js
• une CSP plus stricte avec nonce pour les cas qui en ont besoin

Pour beaucoup de sites marketing ou de portails simples, la premiere approche suffit si elle est bien maintenue.

Le probleme concret avec Supabase

Supabase a souvent besoin de connexions sortantes vers :

• votre endpoint projet
• les appels Auth
• les appels REST ou Realtime selon votre usage

Si votre connect-src est trop strict, certaines operations cessent de marcher :

• login
• lecture de donnees
• upload ou appels supplementaires

Le symptome ressemble souvent a un bug applicatif, alors que le navigateur vous dit deja la verite dans la console : la CSP bloque la requete.

Le probleme concret avec les images externes

Une autre casse frequente concerne les images :

• images CDN
• images Open Graph distantes
• contenus marketing servis depuis un domaine externe

Si img-src ne couvre pas ces origines, les images ne se chargent pas.

Et si vous utilisez next/image, il faut en plus que la configuration Next.js autorise les domaines d'image utiles. La securite se joue donc a deux niveaux :

• la config image de Next.js
• la CSP du navigateur

Le probleme concret avec les scripts analytics

Les outils analytics ou marketing sont aussi des candidats classiques a la casse. Une CSP bien faite doit assumer ce que vous voulez vraiment utiliser.

La question n'est pas "comment faire passer n'importe quel script". La question est :

• quel outil est indispensable ?
• depuis quel domaine se charge-t-il ?
• faut-il autoriser un script, une connexion, une image de tracking, ou plusieurs de ces choses ?

Sans cette clarification, on finit souvent par coller des wildcards un peu partout, et la CSP perd sa valeur.

Une methode propre pour corriger

Voici une methode simple :

1. activez une CSP raisonnablement stricte
2. ouvrez la console navigateur
3. relevez chaque violation reelle
4. identifiez la directive concernee : script-src, connect-src, img-src, style-src, etc.
5. ajoutez seulement l'origine necessaire
6. retestez

Cette approche prend un peu plus de temps qu'un copier-coller global, mais elle produit une politique lisible.

Un exemple de base

Pour un projet Next.js classique, vous pouvez partir d'une structure du type :

Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self' https: data:;
  connect-src 'self' https://your-project.supabase.co;
  frame-ancestors 'self';
  object-src 'none';
  base-uri 'self';

Ensuite, vous ouvrez seulement ce qui est justifie :

• un domaine analytics bien identifie
• un CDN image bien identifie
• un domaine annexe requis par votre stack

Le point important est de garder une liste courte et comprehensible.

Ce qu'il ne faut pas faire

Evitez ces trois erreurs :

• ajouter * partout pour "regler le probleme"
• empiler des domaines sans savoir pourquoi ils sont la
• oublier de retester apres ajout d'un nouvel outil

Une CSP non maintenue finit vite en dette technique. Elle donne un faux sentiment de securite et devient penible a comprendre.

Le bon cadre pour un site Next.js propre

Pour un projet propre en production, gardez cette logique :

• frame-ancestors pour limiter l'embarquement
• object-src 'none'
• base-uri 'self'
• connect-src limite aux APIs reelles
• img-src explicite
• script-src et style-src ouverts seulement si necessaire

Si votre projet grossit ou repose fortement sur des scripts dynamiques, passez ensuite vers une politique plus stricte avec nonce. Mais ne complexifiez pas tout trop tot si le besoin ne l'impose pas encore.

Comment savoir si votre CSP est saine

Posez-vous ces questions :

1. Est-ce que chaque domaine autorise a une raison claire d'exister ?
2. Est-ce que les flux Supabase utiles fonctionnent ?
3. Est-ce que les images et outils analytics essentiels fonctionnent ?
4. Est-ce que vous avez evite les wildcards inutiles ?
5. Est-ce que quelqu'un dans l'equipe peut relire la politique et la comprendre ?

Si la reponse est oui, vous avez deja une base bien meilleure que la plupart des sites.

Ce qu'il faut retenir

Une bonne CSP dans Next.js n'est ni une liste aveugle de blocages, ni une autoroute ouverte a tout. C'est un inventaire clair de ce que votre site charge reellement.

Pour Supabase, les analytics et les images externes, la bonne strategie est toujours la meme : identifier les vraies dependances, ouvrir juste ce qu'il faut, puis retester. C'est cela qui donne une securite utile, sans casser le produit.

Sources officielles

• Next.js - Content Security Policy
• Next.js - headers in next.config.js
• Supabase - Understanding API keys