# Contrôler que rien ne traîne, et le rester

Trois niveaux, du plus concret au plus général. Le premier suffit pour répondre
à « est-ce que j'ai laissé des fichiers en trop ».

---

## Niveau 1 — Comparer le serveur à l'inventaire

`INVENTAIRE.txt` liste les 72 fichiers du déploiement, avec leur empreinte
SHA-256 et leur taille. Tout ce qui est sur le serveur sans y figurer est un
fichier en trop.

Placez-vous dans le dossier de l'archive décompressée :

```powershell
.\verifier-site.ps1
```

Le script se connecte en SFTP, parcourt les dossiers et signale trois choses :
les fichiers en trop, les manquants, et les permissions trop ouvertes sur
`_secrets` et `_storage`.

Si PowerShell refuse de l'exécuter :

```powershell
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
```

Cette autorisation ne vaut que pour la fenêtre en cours.

### À quoi s'attendre

Certains fichiers apparaîtront comme « en trop » sans être problématiques :

| Fichier | Statut |
|---|---|
| `_secrets/twitch.php` | Normal — vos identifiants, jamais distribués |
| `_storage/tokens/twitch.json` | Normal — créé au premier login Twitch |
| `_storage/logs/*.log` | Normal — créés à l'exécution |
| `www-ancien/…` | **À supprimer** une fois la refonte validée |
| `*.bak`, `*~`, `*.save` | **À supprimer** — sauvegardes d'éditeur |
| Tout `.php` inconnu | **À examiner de près** — voir ci-dessous |

Un fichier PHP que vous ne reconnaissez pas dans `www/` mérite un examen
sérieux : c'est la forme que prend un webshell. Ouvrez-le avant de le
supprimer, et si son contenu ressemble à du charabia encodé
(`eval(base64_decode(...))`), changez tous vos mots de passe.

### Sans le script

Le contrôle manuel, dossier par dossier, en sftp :

```
sftp> ls -la www
sftp> ls -la www/assets/js
sftp> ls -la www/creations
```

Et comparez à `INVENTAIRE.txt`. Plus long, mais sans dépendance.

---

## Niveau 2 — Contrôles externes

Ces outils voient votre site comme un visiteur, ou comme un attaquant.

### En-têtes de sécurité

[securityheaders.com](https://securityheaders.com) → `djuju02.fr`

Objectif **A**. Le **A+** demande HSTS, à activer une fois la refonte
stabilisée : décommentez la ligne `Strict-Transport-Security` dans
`www/.htaccess`. Attention, l'engagement dure un an et n'est pas révocable
côté navigateur.

### Configuration TLS

[ssllabs.com/ssltest](https://www.ssllabs.com/ssltest/) → `djuju02.fr`

C'est OVH qui gère votre certificat, vous n'avez pas la main dessus. Le test
sert à détecter un problème de chaîne ou un certificat proche de l'expiration.

### CSP

[csp-evaluator.withgoogle.com](https://csp-evaluator.withgoogle.com)

Collez la valeur de votre en-tête :

```powershell
curl.exe -sI https://djuju02.fr | findstr /i "content-security"
```

L'outil signalera l'absence de `'unsafe-inline'` et `'unsafe-eval'` comme un
bon point. La CSP de `/jeux/` sera notée plus sévèrement, c'est attendu et
documenté dans `www/jeux/.htaccess`.

### Performance et accessibilité

Chrome → F12 → onglet **Lighthouse** → analyser. Testez au moins l'accueil et
Music Roulette. Le jeu aura un score de performance médiocre à cause des ~3 Mo
de Babel ; c'est le sujet traité dans les commentaires de `www/jeux/.htaccess`.

---

## Niveau 3 — Ce qu'aucun outil ne vérifie

### Les secrets

Le point le plus important, et aucun scanner ne le voit.

```powershell
# Aucun secret ne doit apparaître dans les fichiers servis
Select-String -Path .\www\*.php,.\www\**\*.php -Pattern "client_secret|token_key|password" 
```

Sur le serveur, `_secrets/twitch.php` doit être en `600` et
`https://djuju02.fr/_secrets/twitch.php` doit renvoyer `404`.

Et si un secret a transité par un dépôt Git, le changer ne suffit pas : il
reste dans l'historique.

### Les dépendances tierces

Music Roulette charge trois bibliothèques depuis unpkg et cdn.tailwindcss.com.
Elles sont épinglées sur une version précise, ce qui empêche un changement
silencieux. Mais si un de ces CDN était compromis, le code arriverait chez vos
visiteurs. Le seul remède réel est de les héberger vous-même — c'est la
procédure décrite dans `www/jeux/.htaccess`.

### Les permissions, après chaque transfert

FileZilla ne conserve pas toujours les droits. Après un envoi dans
`_secrets`, vérifiez systématiquement :

```
sftp> ls -la _secrets
```

`-rw-------` sur `twitch.php`. Sinon `chmod 600`.

---

## Routine

**Après chaque modification** — le test rapide :

```powershell
foreach ($u in '/','/creations','/jeux','/jeux/music-roulette','/portfolio') {
  "{0,-25} {1}" -f $u, (curl.exe -so NUL -w '%{http_code}' "https://djuju02.fr$u")
}
```

**Une fois par mois** :

- `.\verifier-site.ps1`
- consulter `_storage/logs/php-error.log` (récupérable en sftp)
- sauvegarder `www` et `_secrets` sur votre PC

**Une fois par an, ou après tout incident** :

- régénérer le `client_secret` Twitch
- relancer securityheaders.com et SSL Labs
- vérifier les versions épinglées des CDN du jeu

---

## Une mise au point

« Définitivement sécurisé » n'existe pas. Ce qui existe :

- une **surface d'attaque réduite** — pas de CMS, pas de base de données, pas
  d'upload, pas de compte utilisateur. Votre site est difficile à attaquer
  parce qu'il offre peu de prise, pas parce qu'il est blindé.
- un **état de référence vérifiable** — `INVENTAIRE.txt` permet de répondre à
  « quelque chose a-t-il changé ? », ce qui est la question utile après une
  alerte.
- une **capacité de retour arrière** — vos sauvegardes, plus les snapshots
  quotidiens d'OVH.

Le risque résiduel principal n'est pas technique : c'est un secret qui fuite
par inadvertance, comme c'est arrivé avec `twitch.php` au début de ce projet.
La règle qui protège le mieux tient en une ligne — un fichier de `_secrets/`
ne quitte jamais `_secrets/`.