Aller au contenu

Sécuriser un fichier .json sur un hébergement

    Lorsqu’un site web s’appuie sur un simple fichier .json pour stocker des données (comme le menu d’un restaurant, votre catalogue ou les textes d’une application), il est tentant de le laisser traîner dans le répertoire public. Le problème ? Toute personne pointant son navigateur vers https://monsite.com/menu.json peut alors le télécharger, le modifier s’il trouve une faille et même profiter de droits d’écriture mal configurés pour injecter du contenu malveillant.

    Heureusement, il suffit de quelques réglages pour transformer ce point faible en composant robuste. Dans cet article, je vous montre comment blinder rapidement un fichier .json sans refondre votre architecture.

    Sommaire

    1. Pourquoi protéger son fichier JSON ?
    2. Étape 1 : le rendre inaccessible au navigateur
    3. Étape 2 : verrouiller les permissions d’écriture
    4. Étape 3 : servir le JSON depuis le backend
    5. Étape 4 : vérifier l’intégrité du fichier
    6. Étape 5 : chiffrer les données “au repos” (optionnel)
    7. Étape 6 : sauvegardes et versioning
    8. Bonus : TLS, rate-limit et audit
    9. Conclusion

    Pourquoi protéger son fichier JSON ?

    • Confidentialité : même un menu peut contenir des informations internes (prix négociés, offres spéciales à venir, labels non lancés, etc.).
    • Intégrité : si un attaquant remplace vos plats par des liens malveillants ou du JavaScript, il peut compromettre vos visiteurs.
    • Disponibilité : une mise à jour sauvage (ou un effacement accidentel) casse votre front-end et bloque vos ventes.

    Bref, un petit fichier peut avoir de grosses conséquences.

    Étape 1 : le rendre inaccessible au navigateur

    1.1. Déplacez le fichier hors du “web-root”

    L’idée la plus sûre : stockez menu.json dans un dossier non exposé, par exemple /var/www/data/menu.json. Un dossier data à la racine de votre projet mais en dehors du répertoire public fonctionne très bien.

    1.2. Si vous ne pouvez pas déplacer le fichier …

    Bloquez la lecture via le serveur web.
    Apache (.htaccess)

    <FilesMatch "\.json$">
  Require all denied
</FilesMatch>

    nginx

    location ~* \.json$ {
  deny all;
  return 404;
}

    ✅ Astuce : testez avec curl -I https://votresite.com/menu.json ; vous devez obtenir 403 ou 404, jamais 200.

    Étape 2 : verrouiller les permissions d’écriture

    Même caché, le fichier reste vulnérable si votre processus web peut l’écraser.

    # Propriétaire root, groupe www-data (Apache) ou nginx
chown root:www-data /var/www/data/menu.json

# Lecture pour propriétaire et groupe ; aucune écriture
chmod 640 /var/www/data/menu.json

    Mettre à jour le menu ?

    Créez un petit script (CLI ou tâche cron) exécuté avec un compte disposant temporairement des droits d’écriture ; ainsi, le processus web ne manipule jamais le fichier en direct.

    Étape 3 : servir le JSON depuis le backend

    Plutôt que fetch('/menu.json'), exposez une route contrôlée :

    // Front-end
fetch('/api/menu')
  .then(r => r.json())
  .then(afficherMenu);
    // /api/menu
header('Content-Type: application/json; charset=utf-8');
echo file_get_contents(__DIR__.'/../data/menu.json');

    Avantages :

    1. Contrôle d’accès : vous pourrez restreindre l’endpoint (JWT, cookie signé) ou afficher un “Coming soon”.
    2. Rate-limit & cache : facile de brancher un système de quotas ou d’utiliser Redis/Varnish.
    3. Découplage : changer de format ou de source (base SQL, CMS headless) ne casse pas le front.

    Étape 4 : vérifier l’intégrité du fichier

    Stockez l’empreinte SHA-256 (ou une signature HMAC) ailleurs : variable d’environnement, table SQL, Secret Manager, etc.

    $expected = getenv('MENU_HASH');
$current  = hash_file('sha256', __DIR__.'/../data/menu.json');

if ($current !== $expected) {
    error_log('Alerte : menu.json modifié !');
    http_response_code(503);   // ou 500
    exit('Menu temporairement indisponible');
}

    En prime, envoyez-vous un e-mail ou déclenchez une alerte Slack : vous saurez instantanément qu’un changement inattendu a eu lieu.

    Étape 5 : chiffrer les données “au repos” (optionnel)

    Si vos informations sont sensibles – ou que la RGPD exige une “protection adaptée” – pensez au chiffrement disque ou fichier.

    # Chiffrer
openssl enc -aes-256-cbc -salt -in menu.json -out menu.json.enc

    La clé (passphrase) reste dans une variable d’environnement ou un gestionnaire de secrets (Docker Secrets, AWS KMS, HashiCorp Vault…). Le backend déchiffre à la volée avant d’envoyer le JSON.

    Étape 6 : sauvegardes et versioning

    • Git privé : c’est un versioning incrémental, super léger et rollback en un commit.
    • Sauvegarde quotidienne : un cron rsync vers un stockage chiffré hors-site ou un bucket S3.
    • Automatisation : un pipeline CI peut pousser le fichier dans “main” uniquement après tests (lint, JSON schema).

    Bonus : TLS, rate-limit et audit

    1. HTTPS obligatoire : TLS protège intégrité et confidentialité en transit.
    2. Limiter les requêtes : une règle de type burst 100/m, n=50 sur nginx ou un plan Cloudflare Free suffit souvent à décourager les scrapers.
    3. Audit régulier : un scanner (Arachni, Nikto, Burp) est gratuit et trouve vite les oublis de configuration.

    Conclusion

    Sécuriser un fichier .json n’exige ni Kubernetes ni un budget DevOps ; quelques bonnes pratiques suffisent :

    • Cachez-le, puis donnez-lui le moins de droits possible.
    • Servez-le via votre backend pour contrôler l’accès et la mise en cache.
    • Surveillez l’intégrité et, au besoin, chiffrez-le.
    • Sauvegardez-le comme n’importe quelle pièce critique de votre application.

    Avec ce bouclier minimal, vous protégez vos données, vos visiteurs… et votre réputation. Bon durcissement !