Réussir l’authentification et la sécurité dans Laravel

Prenez un starter kit officiel plutôt que de coder la connexion vous-même. Réécrire une authentification à la main, c’est du bricolage du dimanche. Vous gagnez du temps et vous partez sur une base éprouvée.

Breeze installe l’inscription, la connexion, la réinitialisation de mot de passe, la vérification d’email et la confirmation de mot de passe. Ses vues sont de simples gabarits Blade en Tailwind. C’est le bon choix pour un projet classique ou un premier site.

Jetstream reprend tout Breeze et ajoute la double authentification, la gestion des sessions actives, les jetons d’API et la gestion d’équipes. Choisissez-le quand ces fonctions avancées comptent dès le départ.

Sous le capot, Laravel gère les sessions, hache les mots de passe avec bcrypt ou argon, et protège vos pages avec les middleware auth, guest et verified. Si le framework est nouveau pour vous, notre article Laravel, c’est quoi pose les bases avant de continuer.

Dès que votre application expose une API ou sert une interface monopage, vous avez besoin de jetons plutôt que de simples sessions.

Sanctum est l’option légère. Il authentifie les applications monopages, les mobiles et les API simples avec des jetons faciles à créer et à révoquer. C’est le choix par défaut pour la majorité des cas.

Passport installe un serveur OAuth2 complet. Réservez-le aux besoins qui exigent vraiment la norme entière, par exemple ouvrir votre API à des applications tierces.

Pour construire proprement les points d’entrée qui consommeront ces jetons, suivez notre guide créer une API REST avec Laravel.

Authentifier un utilisateur ne suffit pas. Vous devez aussi décider ce qu’il a le droit de faire. Laravel propose 2 mécanismes complémentaires.

Les Gates sont des fonctions courtes pour des vérifications simples, sans lien avec un modèle précis. Elles conviennent bien à une question comme l’accès à un tableau de bord d’administration.

Les Policies sont des classes dédiées à un modèle ou à une ressource. Elles regroupent au même endroit les règles qui décident qui peut voir, modifier ou supprimer un enregistrement.

La plupart des applications mélangent les 2 sans souci. Un point clé souvent oublié, vérifiez toujours les droits côté serveur, jamais uniquement dans l’affichage.

Une Policy, générée puis remplie.

php artisan make:policy FacturePolicy --model=Facture

namespace App\Policies;

use App\Models\Facture;
use App\Models\User;

class FacturePolicy
{
    public function view(User $user, Facture $facture): bool
    {
        return $user->id === $facture->client_id;
    }

    public function delete(User $user, Facture $facture): bool
    {
        // Une facture payée ne se supprime pas, même par son propriétaire.
        return $user->id === $facture->client_id && $facture->statut !== 'payee';
    }
}

L’appel dans le contrôleur, en 1 ligne. Un refus lève automatiquement une 403.

public function show(Facture $facture)
{
    $this->authorize('view', $facture);
    return new FactureResource($facture);
}

Et dans une vue Blade.

@can('delete', $facture)
    <button>Supprimer</button>
@endcan

⚠ Le piège qui vide une base. authorize() porte sur un objet. Sur une suppression en masse, il faut vérifier chaque ligne, sinon un utilisateur supprime les factures des autres.

// ❌ Aucune vérification par ligne.
Facture::whereIn('id', $request->ids)->delete();

// ✅ On ne supprime que ce qui lui appartient.
Facture::whereIn('id', $request->ids)
    ->where('client_id', $request->user()->id)
    ->delete();

Laravel active plusieurs protections par défaut. La protection CSRF valide vos formulaires avec la directive @csrf. Blade échappe le contenu affiché avec {{ }} pour limiter le XSS. Eloquent utilise des requêtes préparées contre l’injection SQL.

Ajoutez les bons réflexes, et tenez-les. HTTPS partout, chaque entrée validée, les secrets dans le fichier .env, limitez les tentatives de connexion et mettez à jour Laravel, PHP et vos dépendances Composer.

Pour encaisser des paiements, appuyez-vous sur Laravel Cashier, qui relie votre application à Stripe ou Paddle. Laissez le prestataire de paiement gérer les données de carte, ne les stockez jamais vous-même, et exigez HTTPS sur tout le tunnel d’achat. Aucun réglage ne rend un site invulnérable, mais cet ensemble réduit fortement les risques. Quand le site part en ligne, notre guide pour déployer et héberger une application Laravel en France verrouille aussi l’environnement serveur.

La sécurité ne se rattrape pas après coup, elle se pose dans l’architecture. C’est ce que nous faisons dès le premier jour sur les applications que nous développons.

Les 3 protections déjà présentes, et la façon de les désactiver par accident.

// 1. Injection SQL. L’ORM échappe tout seul, sauf si vous concaténez.
User::where('email', $email)->first();                    // ✅
DB::select("select * from users where email = '$email'"); // ❌ injectable

// 2. XSS. Blade échappe par défaut.
{{ $commentaire }}      // ✅ échappé
{!! $commentaire !!}    // ❌ rendu tel quel, à ne jamais faire sur du contenu utilisateur

// 3. CSRF. Le jeton est obligatoire sur tout formulaire POST.

<form method="POST" action="/factures">
    @csrf
    <button>Envoyer</button>
</form>

⚠ La vérification de signature d’un webhook de paiement. C’est le seul moyen de savoir qu’un appel vient bien de votre prestataire et pas de quelqu’un qui a deviné votre adresse.

public function webhook(Request $request)
{
    $signature = $request->header('Stripe-Signature');
    $charge = $request->getContent();
    $secret = config('services.stripe.webhook_secret');

    $attendu = hash_hmac('sha256', $charge, $secret);

    // hash_equals compare en temps constant, ce qui empêche de deviner la signature caractère par caractère.
    if (! hash_equals($attendu, $signature)) {
        abort(403, 'Signature invalide.');
    }

    // Traitement seulement à partir d’ici.
}

⚠ Et ne validez jamais un paiement sur un retour de navigateur. L’adresse de confirmation est visible, donc falsifiable. Seul le webhook signé fait foi.