Authentification gérée côté client en JavaScript

Certains formulaires d’authentification délèguent la vérification des identifiants au JavaScript exécuté dans le navigateur. Les credentials sont alors lisibles directement dans le code source, sans aucun outil particulier.

Le problème

Un formulaire dont le bouton de validation appelle une fonction JavaScript :

<input onclick="Login()" type="button" value="login" name="button">

La fonction Login() contient la logique d’authentification côté client :

function Login() {
    var pseudo   = document.getElementById("pseudo").value;
    var password = document.getElementById("password").value;

    if (pseudo == "rgfreg" && password == "_'nce5") {
        window.location.href = "/dashboard";
    } else {
        alert("Identifiants incorrects");
    }
}

Les identifiants sont codés en dur dans le JavaScript livré au navigateur. N’importe quel visiteur peut les lire.

Exploitation

Lire les identifiants dans les sources

Ouvrir les DevTools (F12), onglet Sources, et rechercher la fonction appelée par le bouton. Les credentials apparaissent en clair dans la condition.

Ou rechercher directement dans les fichiers JavaScript chargés par la page :

Ctrl+Shift+F  →  rechercher "password" ou "pseudo" dans tous les fichiers

Appeler la fonction directement depuis la console

Sans même remplir le formulaire, déclencher la redirection depuis la console :

// Forcer la condition à vrai
Login.toString()  // lire le code de la fonction

// Ou naviguer directement vers la cible
window.location.href = "/dashboard";

Contourner une alert de mot de passe

Le même pattern se retrouve sur des protections par mot de passe via prompt() :

var pass = prompt("Mot de passe :");
if (pass == "secret123") {
    document.getElementById("content").style.display = "block";
}

Depuis la console, court-circuiter la vérification :

document.getElementById("content").style.display = "block";

Ou surcharger prompt pour qu’il retourne directement la bonne valeur :

window.prompt = () => "secret123";

Ce que ça révèle

Ce type d’implémentation indique que :

• aucun endpoint d’authentification n’existe côté serveur : la session n’est pas vérifiée à chaque requête
• la protection repose uniquement sur ce que le JavaScript décide d’afficher ou de masquer
• une fois la redirection connue, accéder à l’URL directement suffit souvent, sans passer par le formulaire

Tester systématiquement les URLs cibles trouvées dans le code JavaScript sans authentification préalable.

Remédiation

L’authentification doit être traitée côté serveur. Le navigateur ne doit jamais être le juge de ce à quoi un utilisateur a accès.

Côté serveur :

// Exemple Node.js / Express
app.post('/login', async (req, res) => {
    const { pseudo, password } = req.body;

    const user = await db.findUser(pseudo);
    if (!user || !await bcrypt.compare(password, user.passwordHash)) {
        return res.status(401).json({ error: 'Identifiants incorrects' });
    }

    req.session.userId = user.id;
    res.redirect('/dashboard');
});

// Protéger chaque route sensible
app.get('/dashboard', requireAuth, (req, res) => {
    res.render('dashboard');
});

Les points à respecter :

• Ne jamais stocker de credentials dans le JavaScript livré au client
• Hacher les mots de passe côté serveur (bcrypt, argon2)
• Vérifier la session à chaque requête vers une ressource protégée, pas seulement à la connexion
• Ne pas se fier à une redirection comme mécanisme de protection : l’URL cible reste accessible directement

À retenir

Tout ce qui s’exécute dans le navigateur est lisible et modifiable. Une condition JavaScript n’est pas un contrôle d’accès. La seule frontière de sécurité valide est le serveur.