Ce que le serveur reçoit. Et ce qu'il ne reçoit pas.

1. Création du secret

Le navigateur génère une clé AES 256 bits aléatoire et un IV de 96 bits. Le texte est ensuite chiffré localement. Laravel reçoit uniquement le ciphertext, l'IV, les règles d'expiration et, le cas échéant, une phrase d'accès destinée au contrôle HTTP.

2. La clé reste dans le fragment URL

La clé est placée après le caractère #. Lors d'une navigation HTTP normale, ce fragment n'est pas envoyé au serveur avec la requête. JavaScript le lit localement afin d'effectuer le déchiffrement.

https://exemple.fr/s/TOKEN#k=CLE_AES

3. Une consultation n'est comptée qu'au clic

Le chargement de la page ne fournit pas le ciphertext. Une requête POST est envoyée uniquement lorsque le destinataire clique sur « Révéler ». Laravel utilise un verrou transactionnel pour éviter deux consommations simultanées du même secret.

4. Limites du modèle

Cette architecture réduit fortement l'exposition du secret côté serveur, mais elle n'est pas une garantie absolue contre un serveur compromis : le JavaScript de chiffrement est lui-même servi par l'application. Un opérateur malveillant capable de modifier ce code pourrait tenter d'exfiltrer des données. Pour les usages à très haut niveau d'assurance, un client auditable séparé est préférable.

5. Mesures complémentaires

• tokens publics et tokens de suppression hashés en base ;
• rate limiting Laravel sur création, lecture et suppression ;
• Cache-Control: no-store sur les pages sensibles ;
• Referrer-Policy: no-referrer ;
• CSP et HSTS activés en production ;
• purge automatique des secrets expirés ou brûlés.