Améliorer la gestion des jetons CSRF pour AJAX dans Laravel 9+ : meilleures pratiques

Question

Dans le contexte de Laravel 9+, les requêtes AJAX doivent exposer les jetons CSRF pour garantir les mesures de sécurité nécessaires. Cependant, différentes méthodes de placement des jetons peuvent affecter l'élégance et l'organisation de votre code. Les deux méthodes principales sont les suivantes :

Méthode 1 : Insérez directement le jeton CSRF via la syntaxe Blade

Dans cette méthode, les cartes de jeton CSRF sont intégrés directement dans JavaScript via la syntaxe Blade. (Répétition du même code à plusieurs endroits)

$(document).ready(function() {
    $.ajaxSetup({
        en-têtes : {
            'X-CSRF-TOKEN' : "{{ csrf_token() }}"
        }
    });
});

≪/pré>
Bien que cette approche maintienne le jeton en dehors du corps du code HTML, elle nécessite l'utilisation de la syntaxe Blade dans le fichier JavaScript, ce qui complique la séparation des préoccupations. 

Méthode 2 : Extraire le jeton CSRF de la balise méta

Cette méthode consiste à placer le jeton CSRF dans la balise méta HTML, puis à l'extraire pour l'utiliser. dans la configuration AJAX. 


 
$(document).ready(function() {
    $.ajaxSetup({
        en-têtes : {
            'X-CSRF-TOKEN' : $('meta[name="csrf-token"]').attr('content')
        }
    });
});
≪/pré>
Dans cette approche, bien que les jetons soient exposés dans le code HTML (ce qui serait le cas de toute façon), cela simplifie la gestion et la réutilisation des fichiers JavaScript et facilite la séparation du code et des problèmes. 

Compte tenu de ce qui précède, je suppose que l'approche 2 est meilleure car elle est plus élégante et permet une meilleure séparation des préoccupations. Ou existe-t-il d'autres bonnes pratiques dans Laravel pour gérer le placement des jetons CSRF lors de l'utilisation de requêtes AJAX afin d'offrir un meilleur équilibre entre sécurité et organisation du code ? Dans l'attente de vos idées. 

PS : j'ai regardé par exemple https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html mais certains d'entre eux dépassent ma compréhension. 

            

Answer 1

Le token n'est exposé qu'aux utilisateurs dont vous souhaitez le posséder (afin qu'ils puissent vous le renvoyer).

Il ne sera exposé à aucun attaquant. (À moins qu'ils n'aient compromis d'une manière ou d'une autre la communication entre le serveur et le navigateur, ce qui signifie qu'ils ont obtenu plus d'accès qu'une attaque CSRF réussie.)

Choisissez l'option directe.