Données · Recherche · Santé

Ne pas inclure la valeur du hash dans l'URL (JavaScript)

Le fragment d’URL (la partie après le caractère #, souvent appelée “hash”) est géré côté client par le navigateur. Il n’est pas envoyé au serveur lors d’une requête HTTP. Cependant, selon vos besoins, vous pouvez vouloir :

  • lire le hash en JavaScript sans qu’il n’apparaisse dans l’URL finale partagée,
  • supprimer le hash après l’avoir lu,
  • ou empêcher totalement son usage dans l’application.

Ce guide présente plusieurs approches pour “ne pas inclure” la valeur du hash dans l’URL affichée tout en conservant sa lecture si nécessaire.

Comprendre le fonctionnement du hash

Le hash d’une URL est accessible via window.location.hash. Exemple :

1
2

// Si l'URL est https://www.nic-ima.be/page#section1
console.log(window.location.hash); // "#section1"

Remarque : le fragment n’est pas envoyé au serveur lors d’un GET - il sert uniquement au navigateur et au code client.

Pour plus d’informations sur location.hash, voir MDN - Location.hash.

Solutions courantes

1) Lire puis supprimer le hash (sans recharger la page)

Si vous souhaitez récupérer l’information contenue dans le hash puis la retirer de la barre d’URL, utilisez l’History API pour remplacer l’entrée d’historique sans rechargement :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// Récupère le hash et enlève le '#' initial
const fragment = window.location.hash ? window.location.hash.substring(1) : null;

if (fragment) {
  // Traitez le fragment ici (p. ex. navigation interne, analytics, etc.)
  console.log('Fragment lu :', fragment);

  // Supprime le fragment de l'URL sans recharger la page
  const { protocol, host, pathname, search } = window.location;
  const newUrl = `${protocol}//${host}${pathname}${search}`;
  window.history.replaceState(null, '', newUrl);
}

Explication :

  • window.history.replaceState permet de modifier l’URL affichée sans effectuer de navigation ni rechargement.
  • On reconstruit l’URL sans la partie hash.

2) Remplacer le hash immédiatement à la charge (pour URL partagées)

Si vous recevez des visiteurs avec un hash (par partage d’URL) mais que vous voulez le masquer après lecture :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

document.addEventListener('DOMContentLoaded', () => {
  const fragment = location.hash ? location.hash.slice(1) : null;
  if (fragment) {
    // Utilisation du fragment
    handleFragment(fragment);

    // Supprimer le hash
    history.replaceState(null, '', location.pathname + location.search);
  }
});

Veillez à traiter le fragment avant de l’effacer si vous en avez besoin pour initialiser l’état de la page.

3) Empêcher l’ajout du hash côté application

Si votre application ajoute des fragments via ancre () et que vous voulez empêcher leur apparition, gérez les clics et interceptez le comportement par défaut :

1
2
3
4
5
6
7
8
9

document.addEventListener('click', (e) => {
  const el = e.target.closest('a[href^="#"]');
  if (!el) return;

  e.preventDefault();
  const targetId = el.getAttribute('href').slice(1);
  navigateToFragment(targetId); // votre fonction de navigation
  // Ne pas laisser le navigateur ajouter le hash
});

Cette approche garde la navigation basée sur fragments sans modifier l’URL.

4) Encodage et sécurité

Si vous utilisez la valeur du hash pour transmettre des données, encodez-les correctement (encodeURIComponent) et ne faites jamais confiance aux données côté client sans validation. Le fragment étant manipulable côté client, il ne convient pas pour des secrets.

5) Cas des applications à page unique (SPA)

Dans les SPA, deux modes d’URL sont courants :

  • Hash-based routing (/#/route)
  • History API (pushState/replaceState) pour URLs “propres”

Si vous voulez éviter le hash complètement, utilisez l’API History pour gérer le routage côté client et servez un fallback côté serveur (rediriger toutes les routes vers l’index de l’app). Exemple basique pour pushState :

1
2
3
4
5

// Naviguer sans hash
function navigate(path) {
  history.pushState({}, '', path);
  // charger le contenu correspondant à path
}

Attention : le serveur doit être configuré pour renvoyer l’application pour ces routes.

Bonnes pratiques

  • Si le serveur ne doit pas connaître la valeur, n’envoyez pas la donnée via query string ou POST : utilisez exclusivement le fragment côté client.
  • Supprimez le hash si nécessaire après lecture pour garder une URL “propre” pour le partage.
  • Pour un routage moderne, préférez l’History API aux fragments si vous pouvez configurer le serveur en conséquence.
  • Toujours valider et normaliser les données extraites du hash avant usage.

Résumé

  • Le hash n’est pas envoyé au serveur par défaut.
  • Pour “ne pas inclure” le hash dans l’URL affichée, lisez-le puis utilisez history.replaceState pour supprimer le fragment sans recharger la page.
  • Pour éviter qu’il n’apparaisse du tout, interceptez les interactions qui l’ajoutent ou utilisez une stratégie de routage différente (History API).
  • Encodez et validez toutes les données récupérées du hash.

Si vous souhaitez, je peux ajouter des extraits adaptés à votre code existant, expliquer comment configurer le serveur pour le routage History API, ou proposer une version compatible avec des frameworks spécifiques (React, Vue, Angular).

Partager :