# Audit de djuju02.fr — état des lieux et corrections

Analyse des fichiers fournis, hébergement OVH mutualisé **PERSO** (cluster100, eu-west-gra, PHP 8.2).

---

## 🔴 Critique — à traiter maintenant

### C1. Le `client_secret` Twitch est compromis

`_secrets/twitch.php` contenait en clair :

```
client_id     = [client_id, non secret, retiré par précaution]
client_secret = [SECRET RÉVOQUÉ — ne jamais écrire une clé dans la doc]
```

Ce fichier a été transmis dans une conversation. **Considérez le secret comme public.** Avec ce couple, un tiers peut obtenir des jetons d'application au nom de votre app Twitch, usurper votre identité applicative et consommer votre quota d'API.

**Action, dans cet ordre :**

1. https://dev.twitch.tv/console/apps → votre application → **New Secret**. L'ancien est révoqué immédiatement.
2. Reportez la nouvelle valeur dans `_secrets/twitch.php` sur le serveur (jamais ailleurs).
3. `chmod 600 ~/_secrets/twitch.php`
4. Vérifiez la liste des OAuth Redirect URLs de l'app : une seule entrée, exactement `https://djuju02.fr/twitch/api/oauth_callback.php`.
5. Si le fichier a transité par un dépôt Git, changer le secret ne suffit pas — il reste dans l'historique. Purgez-le (`git filter-repo`) ou repartez d'un dépôt neuf.

Le `client_id` n'est pas un secret (il est visible dans l'URL d'autorisation), inutile de le changer.

**Ce qui était déjà bien :** le chemin `/home/djujufm/_secrets/twitch.php` est hors de la racine web. C'est le bon réflexe, on le conserve.

### C2. Aucun `state` dans le flux OAuth

Le fichier de config déclare un `redirect_uri` mais rien dans le code fourni ne gérait le paramètre `state`. Sans lui, un attaquant peut construire un lien de callback qui lie **son** compte Twitch à **votre** session (CSRF de connexion).

**Corrigé** : `oauth_start.php` génère un `state` de 32 octets, le stocke en session avec une expiration de 10 min ; `oauth_callback.php` le vérifie avec `hash_equals()` et le consomme immédiatement.

### C3. Les jetons n'avaient pas d'emplacement de stockage défini

**Corrigé** : `_storage/tokens/twitch.json`, hors racine web, chiffré en AES-256-GCM, écrit en 0600 de façon atomique. Le rafraîchissement est automatique avec 60 s de marge.

---

## 🟠 Élevé

### E1. CSP en balise `<meta>`, avec `'unsafe-inline'` partout

```html
<meta http-equiv="Content-Security-Policy" content="... script-src 'self' 'unsafe-inline' ...">
```

Trois problèmes :

- `'unsafe-inline'` sur `script-src` annule l'essentiel de la protection XSS : c'est exactement ce qu'une injection cherche à exécuter.
- Une balise `<meta>` ne protège que ce qui vient **après** elle dans le document, et ne couvre ni les erreurs 404/500, ni les réponses non-HTML.
- La politique était différente d'une page à l'autre (`overlays.html` autorisait `images.unsplash.com`, pas les autres).

**Corrigé** : CSP unique envoyée en en-tête HTTP depuis `www/.htaccess`, sans `'unsafe-inline'` pour les scripts. Tout le JS est externalisé. Exception documentée et isolée pour `/jeux/` (`www/jeux/.htaccess`), le temps d'externaliser le JS des jeux.

### E2. Aucun en-tête de sécurité, aucun forçage HTTPS

Il n'y avait pas de `.htaccess`. Manquaient : redirection HTTPS, `X-Content-Type-Options`, `Referrer-Policy`, `Permissions-Policy`, `frame-ancestors`, `Options -Indexes`.

Conséquence concrète de `Options -Indexes` manquant : `https://djuju02.fr/assets/img/` listait tout le dossier.

**Corrigé** : voir `www/.htaccess`, sections 1, 2 et 4. HSTS est fourni **commenté** — à n'activer qu'après avoir confirmé que tous vos sous-domaines sont en HTTPS, sinon vous vous bloquez l'accès pendant un an.

### E3. Formulaire de contact absent, page Contact pointant dans le vide

Le menu proposait « Contact » → `portfolio/index.html#contact`, mais aucun traitement n'existait. Un formulaire PHP naïf est la première porte d'entrée pour du spam relayé (injection d'en-têtes SMTP via `\r\n` dans le champ e-mail).

**Corrigé** : `www/contact-envoi.php` — POST uniquement, jeton CSRF vérifié en temps constant, honeypot, limite d'un envoi par minute, validation stricte, et suppression des `\r\n` avant de construire `Reply-To`.

---

## 🟡 Moyen

### M1. La navbar était dupliquée dans chaque page — et se contredisait

Chaque page redéfinissait la navbar en `<style>` **puis** chargeait `shared-nav.css`. Les deux ne parlaient pas le même langage :

| Comportement | CSS inline de `index.html` | `shared-nav.css` | `shared-nav.js` |
|---|---|---|---|
| Sous-menu ouvert (mobile) | `.nav-item.active` | `.nav-item.submenu-open` | pose `submenu-open` |
| Menu mobile ouvert | `height: 0` → `calc(100vh - 60px)` | `opacity` / `visibility` / `transform` | pose `active` |
| Survol du sous-menu | `.nav-item:hover` (toutes les entrées) | `.nav-item.has-submenu:hover` | — |

Le JS posait `submenu-open`, mais le CSS d'`index.html` n'écoutait que `.active` : sur la page d'accueil en mobile, la flèche du sous-menu ne tournait pas et la hauteur du menu était pilotée par deux mécanismes concurrents. `.nav-item:hover .arrow-icon` faisait par ailleurs pivoter une flèche sur des entrées qui n'en ont pas.

**Corrigé** : la navbar n'existe plus qu'à deux endroits — `_app/partials/nav.php` pour le HTML, `assets/css/shared-nav.css` pour le style. Zéro `<style>` dans les pages.

### M2. Flash blanc au chargement en thème sombre

`shared-nav.js` appliquait `.dark-mode` sur `DOMContentLoaded`, donc après le premier rendu : la page apparaissait blanche puis basculait en noir.

**Corrigé** : `assets/js/theme-init.js`, minuscule et **bloquant** dans le `<head>`, pose la classe sur `<html>` avant le premier pixel. Il respecte aussi `prefers-color-scheme` quand l'utilisateur n'a jamais choisi.

### M3. Images tierces en hotlink

`overlays.html` chargeait ses visuels depuis `images.unsplash.com`. Cela impose d'ouvrir la CSP à un domaine externe, expose l'IP de vos visiteurs à un tiers, et casse la page le jour où l'URL change.

**Corrigé** : les visuels sont attendus dans `www/assets/img/overlays/`. La CSP `img-src 'self' data:` redevient stricte.

### M4. Accessibilité

- Les déclencheurs de sous-menu étaient des `<a href="#">` : au clavier, ils naviguaient au lieu d'ouvrir. → remplacés par des `<button type="button">` avec `aria-controls` / `aria-expanded`.
- Aucun lien d'évitement. → `.skip-link` ajouté.
- Aucun `aria-current` sur la page active. → ajouté.
- Le bouton de thème n'indiquait pas son état. → `aria-pressed` synchronisé.
- Aucune prise en compte de `prefers-reduced-motion`. → ajoutée dans `base.css`.

### M5. SEO et partage

Aucune `meta description`, aucun Open Graph, aucun `canonical`, pas de `robots.txt`, pas de `sitemap.xml`, pas de page 404. Un lien du site collé dans Discord ou un panneau Twitch n'affichait aucun aperçu.

**Corrigé** : tout est généré depuis `_app/partials/head.php` à partir du tableau `$page` de chaque page. `robots.txt`, `sitemap.xml`, `404.html`, `403.html`, `500.html` ajoutés.

### M6. Aucun cache, aucune compression

**Corrigé** : `mod_deflate` + `mod_expires` dans `.htaccess`. Les assets sont servis avec `?v=<mtime>` via la fonction `asset()`, donc cachables un an sans risque de servir une version périmée.

---

## 🔵 Faible / hygiène

- **`html { overflow-y: scroll }`** était répété dans chaque page → centralisé dans `base.css`.
- **`.tag.animated` / `.tag.static`** : `animated` et `static` sont des noms trop génériques, susceptibles d'entrer en collision avec une future classe utilitaire → renommés `.tag-animated` / `.tag-static`.
- **`display: none` sur `.sun-icon`** était déclaré à trois endroits différents → une seule déclaration.
- **`_bash_profile`** : `umask 077` ajouté (sur un mutualisé, les fichiers créés en SSH ne doivent pas être lisibles par les voisins), plus `HISTIGNORE` pour ne pas laisser un secret traîner dans l'historique shell.
- **Pas de `.ovhconfig`** : la version de PHP dépendait du réglage global du panneau. Fichier ajouté, épinglé sur 8.2 avec `environment=production`.
- **Pas de `.gitignore`** : c'est très probablement ainsi que `twitch.php` a fini par circuler. Ajouté, avec `_secrets/*` exclu et seul `*.example` conservé.

---

## Checklist post-déploiement

- [ ] Nouveau `client_secret` Twitch généré et l'ancien révoqué
- [ ] `chmod 600 ~/_secrets/twitch.php` vérifié
- [ ] `token_key` généré (`php -r "echo bin2hex(random_bytes(32));"`)
- [ ] `https://djuju02.fr/_secrets/twitch.php` renvoie 404 (et non le fichier)
- [ ] `https://djuju02.fr/assets/img/` renvoie 403 (et non un listing)
- [ ] `http://djuju02.fr` redirige bien en 301 vers `https://`
- [ ] Les anciennes URLs `.html` redirigent en 301
- [ ] Aucune erreur CSP dans la console du navigateur
- [ ] Test sur https://securityheaders.com (objectif : A ou A+)
- [ ] Menu mobile testé sur un vrai téléphone
- [ ] HSTS décommenté **seulement après** validation complète du HTTPS

---

# Compléments — après réception des fichiers manquants et de la capture FTP

## 🔴 Nouveau point critique : permissions des dossiers sensibles

La capture FileZilla montre :

```
_secrets   drwxr-xr-x   djujufm users
private    drwxr-xr-x   djujufm users
www        drwxr-xr-x   djujufm users
```

`drwxr-xr-x` = **lisible et traversable par tout le monde**. Sur un hébergement
mutualisé, « tout le monde » inclut les autres clients hébergés sur le même
cluster (ici cluster100). Un dossier nommé `_secrets` en 755 est une invitation.

```bash
chmod 700 ~/_secrets ~/private
chmod 600 ~/_secrets/*
```

Vérifiez aussi le propriétaire du groupe : `users` est un groupe partagé.

## 🟠 Le `.htaccess` à la racine du home

Il y a un `.htaccess` de 1401 octets dans `/home/djujufm/`, daté du 08/09/2025.
Deux cas de figure, à trancher avant toute manipulation :

- **Si la racine du site en multisite est `www`** : Apache ne lit jamais ce
  fichier (il ne remonte pas au-dessus du DocumentRoot). Il est inerte, mais
  il révèle qu'il a pu servir à autre chose auparavant.
- **Si la racine du site est `/`** : alors `_secrets/` et `private/` sont
  servis en HTTP, et seul ce `.htaccess` vous protège. C'est une configuration
  à corriger immédiatement.

Pour trancher :

```bash
curl -sI https://djuju02.fr/_secrets/twitch.php | head -1
```

`404` → la racine est bien `www`, tout va bien.
`403` → la racine est `/` et vous êtes protégé uniquement par le `.htaccess`.
`200` → **votre `client_secret` est en libre accès sur Internet.**

Dans les deux derniers cas : espace client OVH → Hébergements → Multisite →
modifier le dossier racine du domaine pour `www`.

## 🟠 Le JavaScript du portfolio ne s'exécutait pas

Le `<script>` de `portfolio/index.html` contenait des accolades orphelines :

```js
document.addEventListener('DOMContentLoaded', () => {
    const body = document.body;
    }        // ← de trop
    });      // ← de trop
```

Un fichier JS est analysé en entier avant d'être exécuté : cette erreur de
syntaxe empêchait **tout le bloc** de se charger. `openModal()` et
`closeModal()` n'étaient donc jamais définies — cliquer sur un projet ne
faisait rien du tout. L'erreur vient probablement de la suppression du code
de thème sans nettoyage des accolades.

Corrigé dans `assets/js/portfolio.js`, avec au passage la suppression des
attributs `onclick=` (interdits par la CSP) au profit d'une délégation
d'événements, l'ouverture au clavier, la fermeture par Échap et le retour du
focus sur la carte d'origine.

## 🟠 Music Roulette : ~3 Mo de JavaScript à chaque première visite

Le jeu est une application React **compilée dans le navigateur** par Babel
standalone, mise en forme par Tailwind CDN. Conséquences :

| Aspect | Situation |
|---|---|
| Poids | Babel standalone ≈ 3 Mo, téléchargés avant le premier affichage |
| Délai | La compilation JSX ajoute plusieurs centaines de ms, surtout sur mobile |
| CSP | Babel et Tailwind exigent `'unsafe-eval'` |
| Versions | `react@18` et `cdn.tailwindcss.com` sans numéro : le contenu peut changer sans préavis |
| Tiers | unpkg.com et cdn.tailwindcss.com voient l'IP de chaque joueur |

Traité ainsi :

- versions **épinglées** (`react@18.3.1`, `@babel/standalone@7.24.7`,
  `tailwindcss/3.4.1`) — le jeu redevient reproductible ;
- JSX et CSS **externalisés** dans `/assets/`, donc mis en cache et plus
  besoin de `script-src 'unsafe-inline'` ;
- CSP permissive **confinée à `/jeux/`** via `www/jeux/.htaccess`, avec la
  liste précise des domaines (`itunes.apple.com` pour la recherche,
  `*.mzstatic.com` pour les pochettes et les extraits audio) ;
- la marche à suivre pour précompiler et supprimer l'exception est écrite en
  commentaire dans ce `.htaccess`.

Le reste du site conserve une CSP stricte, sans `'unsafe-eval'` ni
`'unsafe-inline'`.

## 🟡 `.ovhconfig` : je m'étais trompé d'emplacement

Je l'avais placé dans `www/`. Votre serveur montre qu'il est à la racine du
home — et c'est bien là qu'OVH le lit. Corrigé : `/home/djujufm/.ovhconfig`.

## 🟡 Le portfolio exposait une adresse e-mail en clair

`<a href="mailto:contact@djuju02.fr">` fonctionne, mais une adresse en clair
dans le HTML est aspirée par les robots à spam en quelques jours. Remplacée
par le formulaire sécurisé (CSRF, honeypot, anti-injection d'en-têtes,
limitation à un envoi par minute).

## 🟡 Sélecteur CSS trop large dans le portfolio

`section { padding: 80px 5%; max-width: 1200px }` — un sélecteur d'élément nu.
Tant que la page était isolée, aucun souci ; une fois les feuilles mutualisées,
il s'appliquait à toutes les `<section>` du site, y compris celles des autres
pages. Renommé `.pf-section`.

---

# Correctif d'audit — après lecture du `.htaccess` réel

Deux affirmations de la première version étaient fausses. Rectification.

## « Il n'y avait pas de `.htaccess` » — faux

Il y en avait un, à `/home/djujufm/.htaccess`, daté du 08/09/2025. Je jugeais
sur les seuls fichiers transmis, où il ne figurait pas.

Il est bien appliqué : OVH déclare son bloc `<Directory>` sur `/home/djujufm`,
donc Apache lit les `.htaccess` à partir de ce niveau puis descend vers `www/`.
C'est ce qui explique la présence des en-têtes `X-Content-Type-Options`,
`X-Frame-Options`, `Referrer-Policy` et `Permissions-Policy` alors que `www/`
ne contenait aucun fichier de configuration.

Il couvrait déjà : HTTPS forcé, canonicalisation sans `www`, quatre en-têtes de
sécurité, cache long sur les assets, `Options -Indexes`. Du travail correct.
Le niveau d'exposition était donc plus faible que ce que j'annonçais.

Restaient absents : la Content-Security-Policy, le blocage des fichiers
sensibles, les pages d'erreur, la compression, et l'interdiction d'exécuter du
PHP dans les dossiers d'assets.

## 🟠 Bug latent : boucle de redirection HTTPS

```apache
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
```

Le `[OR]` déclenche la redirection dès qu'**un** des deux signaux n'indique pas
HTTPS. Sur un mutualisé OVH, le TLS est terminé par un proxy en amont :

- `%{HTTPS}` peut valoir `off` pour un visiteur pourtant en HTTPS ;
- `X-Forwarded-Proto` peut ne pas être transmis, auquel cas `!https` est vrai.

Dans les deux cas, la condition reste vraie **après** la redirection : le
navigateur boucle sur des 301 jusqu'à abandonner, et le site devient
inaccessible.

Ça ne se déclenche pas aujourd'hui parce que les deux signaux sont cohérents
sur votre configuration actuelle. C'est une dépendance à un détail
d'infrastructure que vous ne maîtrisez pas.

Corrigé dans `www/.htaccess` : deux `RewriteCond` sans `[OR]` sont combinées en
ET par Apache, donc la redirection ne se produit que si aucun des deux signaux
n'indique HTTPS.

## Emplacement retenu

La configuration passe dans `www/.htaccess` et celui de la racine est vidé de
ses règles (contenu d'origine conservé en commentaire).

Deux raisons. D'abord, vous avez droit à cinq sites : une règle placée au
niveau du home s'appliquerait à tous, y compris à un futur sous-domaine qui
n'en veut pas. Ensuite, Apache exécute les deux fichiers l'un après l'autre —
deux redirections HTTPS et deux blocs de cache superposés produisent des
comportements pénibles à diagnostiquer.

## `X-Frame-Options`

Vous aviez `SAMEORIGIN`, j'ai retenu `DENY` avec `frame-ancestors 'none'`.
Sans effet sur OBS, dont les sources navigateur ignorent cet en-tête. Mais si
vous intégrez une de vos pages dans une iframe sur votre propre site, repassez
à `SAMEORIGIN` et `frame-ancestors 'self'` — les deux lignes sont commentées à
cet endroit du fichier.

## Permissions — corrigé le 05/08

`_secrets` et `private` étaient en `drwxr-xr-x`, lisibles par les autres
comptes du cluster100. Passés en `drwx------`, et `_secrets/twitch.php` en
`600`. Vérifié.

`_secrets` renvoie bien un `404` en HTTP : il est hors de la racine web, la
racine multisite est correctement réglée sur `www`.

---

# Ajout du répertoire /overlays/

## Ce qui est bon dans ce dossier

Audit du code fourni : rien à redire sur le fond.

- `textContent` partout, jamais `innerHTML` pour insérer une valeur — les
  paramètres d'URL ne peuvent donc pas devenir du HTML exécutable ;
- aucun `<style>`, aucun `<script>` en ligne, aucun attribut `onclick` ;
- aucune ressource externe : ni Google Fonts, ni CDN. Rien ne fuit vers un
  tiers pendant que vos viewers regardent le stream ;
- CSP en `default-src 'none'` avec `'self'` sur les seules directives utiles.
  C'est plus strict que la politique du site principal, et nettement plus que
  l'exception `/jeux/`.

## 🔴 Ce qui manquait : le dossier `twitch/`

Le zip ne contenait plus `www/twitch/`. Or ce répertoire porte tout le flux
OAuth : `oauth_start.php`, `oauth_callback.php` et la page d'état.

Le déployer tel quel aurait cassé l'autorisation Twitch. Le `redirect_uri`
déclaré dans votre console développeur pointe sur
`https://djuju02.fr/twitch/api/oauth_callback.php` — une URL en 404 fait
échouer l'échange de jetons, et Twitch refuse toute modification du
`redirect_uri` sans revalidation de l'application.

`twitch/` est conservé. Les deux répertoires cohabitent sans se gêner : ils
n'ont ni URL, ni fichier, ni politique de sécurité en commun.

## 🟡 `?api=` acceptait n'importe quelle URL

```js
var url = params.get("api");
fetch(url, { cache: "no-store" })
```

L'URL vient de la barre d'adresse. Un lien piégé du type
`/overlays/labels.html?api=https://exemple-malveillant/x.json` faisait émettre
une requête vers un domaine tiers.

La portée réelle était faible : `connect-src 'self'` bloque déjà l'appel, et
les valeurs récupérées passent par `textContent`. Mais faire reposer la
protection sur un seul mécanisme est fragile — une CSP mal recopiée dans un
futur `.htaccess` suffirait à rouvrir la voie.

Ajouté dans `overlays.js` : seuls les chemins relatifs internes (`/…`) sont
acceptés, tout le reste est ignoré silencieusement.

## 🟡 Trois incohérences d'intégration

**`robots.txt`** avait perdu `Disallow: /twitch/api/` et n'excluait pas
`/overlays/`. Rétabli et complété.

**`.htaccess` racine** appliquait ses règles d'URL propre à `/overlays/`.
Un lien collé dans Streamlabs se serait mis à rediriger, et une source
navigateur qui reçoit une 301 peut échouer selon la version d'OBS. Ajout de
`RewriteRule ^overlays/ - [L]` : le répertoire est désormais servi tel quel.

**`assets/fonts/`** était absent du zip alors que `core.css` l'attend. Créé,
avec une note expliquant où récupérer Orbitron et Rajdhani — et pourquoi ne
surtout pas les remplacer par un lien Google Fonts, qui exposerait l'IP de vos
viewers à chaque affichage.

## 🟡 La vitrine mentait

`creations/overlays.php` présentait deux packs fictifs, « Neon Cyber » et
« Minimal Clean », avec des images de remplacement — alors que dix overlays
réels existent désormais.

Page refaite : elle liste les dix, avec leurs dimensions exactes pour
Streamlabs, un lien de prévisualisation, et un mode d'emploi. Les fausses
vignettes disparaissent, ce qui règle au passage deux placeholders.

Les cartes n'ont plus de vignette. Quand vous ferez des captures, déposez-les
dans `assets/img/overlays/` et ajoutez une clé `image` au tableau `$overlays`.

## Note sur les deux « overlays »

Il existe maintenant deux URL proches, et c'est volontaire :

| URL | Rôle |
|---|---|
| `/creations/overlays` | Vitrine publique, indexée, dans le menu |
| `/overlays/` | Les overlays réels, `noindex`, à coller dans OBS |

La galerie `/overlays/` reste accessible à qui connaît l'adresse. Ce n'est pas
un secret — ce sont des habillages destinés à être affichés en direct — mais
si vous préférez la fermer, une authentification HTTP basique suffit :
`htpasswd` dans le `.htaccess` du répertoire. À ne pas mettre sur les fichiers
d'overlay eux-mêmes : OBS ne saurait pas s'authentifier.