---
name: feedback-auth-page-no-secret-leak
description: "Mai incorporare una credenziale vera in una pagina/risposta pensata per chi non è ancora autenticato, nemmeno per comodità UX"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: c2380614-2d9a-4e52-a5f8-5189ab822c01
  modified: 2026-08-06T11:45:28.028Z
---

Quando si costruisce una pagina di "accesso negato"/login per un meccanismo di auth
applicativa (cookie/token/password), non incorporare mai la credenziale vera nell'HTML,
in un link, o in qualunque risposta servita a chi non ha ancora dimostrato di conoscerla —
anche se sembra un'ottimizzazione UX innocua ("un click invece di doverla scrivere").

**Perché**: durante il lavoro su voice-chat (06/08/2026, progetto smantellato 12/08/2026) ho sostituito la Basic Auth
di Caddy con un cookie applicativo, poi — per rendere leggibile su mobile la pagina di
errore 403 — ho aggiunto un link "Apri con la chiave salvata" che conteneva la password
vera in chiaro nell'URL/HTML della pagina stessa. Risultato: chiunque arrivasse sull'URL
senza sapere nulla vedeva comunque il bottone e con un click entrava — la protezione era
di fatto annullata per chiunque scoprisse l'URL, il contrario esatto dell'obiettivo. Mauro
l'ha notato subito con una domanda diretta ("come mai non serve più password?"), non l'ho
verificato da solo prima di considerarlo finito.

**Come applicare**: prima di considerare completa una pagina di login/accesso-negato,
controllare esplicitamente che la risposta HTTP (HTML, JSON, header, link) non contenga la
credenziale vera in nessuna forma — solo un campo di input che l'utente deve compilare.
Vale anche per redirect URL, messaggi di errore "verbose" che a volte echo-ano input
dell'utente, o link "di comodo" pre-compilati. Un test rapido: `curl` sulla pagina di
errore e grep per la credenziale — se compare, è un bug di sicurezza, non un dettaglio.