Skip to content

Chapitre 6.5 : Fondamentaux de la sécurité des API

Temps d'étude : 45 minutes

1. Sécurité des API : Une défense de station à plusieurs niveaux

Imaginez que votre station spatiale (API) se trouve dans un secteur hostile de l'espace. Un seul champ de force (authentification) ne suffit pas. Vous avez besoin d'un système de défense complet :

  • Boucliers (HTTPS) : Chiffrement de tout le trafic.
  • Capteurs d'anomalies (Rate Limiting) : Protection contre les requêtes trop fréquentes.
  • Cloisons internes (Autorisation) : Séparation des droits d'accès.
  • Inspection des cargaisons (Validation) : Ne faire confiance à aucune donnée entrante.
  • Coffre-fort secret (Variables d'environnement) : Stockage sécurisé des clés.

Paramétrons chacun de ces niveaux.

2. Boucliers : Toujours utiliser HTTPS

Qu'est-ce que c'est ? HTTPS (HyperText Transfer Protocol Secure) est une version du protocole HTTP qui chiffre toutes les données entre le client et le serveur. Sans lui, quiconque "écoute" le réseau (par exemple, dans un Wi-Fi public) peut intercepter les identifiants, mots de passe et jetons.

Comment implémenter ?

  • En production — obligatoire. Lors du déploiement de votre API sur un serveur réel (Heroku, DigitalOcean, etc.), configurez le serveur web (Nginx, Apache) pour qu'il fonctionne avec un certificat SSL. Des services comme Let's Encrypt fournissent des certificats gratuits.
  • En développement local c'est moins critique, mais des outils comme Laravel Herd ou mkcert permettent de configurer facilement le HTTPS local.

💡 Règle n°1 de la sécurité des API : Pas de HTTPS — pas de sécurité.

3. Capteurs d'anomalies : Limitation du taux de requêtes (Rate Limiting)

Qu'est-ce que c'est ? Protection contre les attaques par force brute (lorsqu'un attaquant tente de deviner un mot de passe en envoyant des milliers de requêtes par seconde) et contre les attaques DoS (lorsque le serveur est "submergé" de requêtes pour le rendre indisponible). Le Rate Limiting limite le nombre de requêtes qu'un utilisateur (ou une adresse IP) peut effectuer dans un laps de temps donné.

Comment implémenter ?

  • Dans Laravel : Le middleware de limitation est déjà intégré ! Ouvrez app/Http/Kernel.php et regardez la clé middlewareGroups['api']. Il y a déjà 'throttle:api'. Les paramètres de cette limitation se trouvent dans app/Providers/RouteServiceProvider.php dans la méthode configureRateLimiting(). 

    // app/Providers/RouteServiceProvider.php
protected function configureRateLimiting()
{
    RateLimiter::for('api', function (Request $request) {
        return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
    });
}
    Cela signifie : 60 requêtes par minute par utilisateur (s'il est authentifié) ou par adresse IP.

  • Dans FastAPI : Un paquet tiers est utilisé, par exemple, slowapi.

  • Installation : pip install slowapi

  • Intégration dans main.py : 
    # main.py
from slowapi import Limiter, _rate_limit_exceeded_handler
from slowapi.util import get_remote_address
from slowapi.errors import RateLimitExceeded

limiter = Limiter(key_func=get_remote_address)
app = FastAPI(...)

# On connecte le gestionnaire d'exceptions et le limiteur lui-même
app.state.limiter = limiter
app.add_exception_handler(RateLimitExceeded, _rate_limit_exceeded_handler)

# Appliquer à un point de terminaison spécifique
@router.get("/planets")
@limiter.limit("5/minute") # 5 requêtes par minute
def get_planets(request: Request):
    # ...

4. Cloisons internes : Autorisation (à ne pas confondre avec l'authentification !)

Qu'est-ce que c'est ?

  • L'authentification répond à la question "Qui es-tu ?".
  • L'autorisation répond à la question "Qu'as-tu le droit de faire ?".

Par exemple, un utilisateur ordinaire peut consulter les planètes, mais seul un utilisateur avec le rôle "administrateur" peut les supprimer.

Comment implémenter ?

  • Dans Laravel : Les Policies (Politiques) ou les Gates (Portails) sont utilisés.

  • Création d'une politique : php artisan make:policy PlanetPolicy --model=Planet

  • Description des règles dans app/Policies/PlanetPolicy.php : 
    class PlanetPolicy
{
    // Autoriser la suppression uniquement aux utilisateurs avec le rôle 'admin'
    public function delete(User $user, Planet $planet): bool
    {
        return $user->role === 'admin';
    }
}

  • Application de la politique dans le contrôleur PlanetController.php : 

    public function destroy(Planet $planet)
{
    // On vérifie si l'utilisateur actuel a le droit de supprimer
    $this->authorize('delete', $planet);

    $planet->delete();
    return response()->json(null, 204);
}

  • Dans FastAPI : La logique d'autorisation est généralement écrite manuellement à l'intérieur des points de terminaison, en utilisant les informations utilisateur obtenues à partir du jeton.

# (nous supposons que le jeton contient un champ 'roles')
def get_current_active_user(token: str = Depends(oauth2_scheme)):
    # ... nous décodons le jeton et obtenons l'utilisateur avec les rôles de la base de données
    # user = get_user_from_db(username)
    return user # retourne l'objet utilisateur

@router.delete("/planets/{planet_id}")
def delete_planet(
    planet_id: int,
    current_user: User = Depends(get_current_active_user)
):
    if "admin" not in current_user.roles:
        raise HTTPException(
            status_code=status.HTTP_403_FORBIDDEN,
            detail="Droits insuffisants pour effectuer cette opération",
        )
    # ... logique de suppression ...

5. Inspection des cargaisons et Coffre-fort secret : Validation et Variables d'environnement

Nous avons déjà implémenté ces deux points, mais il est important de souligner leur rôle dans la sécurité.

  • Ne jamais faire confiance aux données entrantes (Validation) :

  • Nous avons utilisé $request->validate() dans Laravel et les modèles Pydantic dans FastAPI. Cela nous protège des injections SQL (lors de l'utilisation d'Eloquent/SQLAlchemy) et des données incorrectes qui pourraient casser l'application. Toujours valider tout ce qui vient de l'extérieur !

  • Stocker les secrets dans .env (Variables d'environnement) :

  • Les clés de bases de données, les clés secrètes pour JWT (SECRET_KEY), les clés de services tiers — tout cela ne doit jamais être inclus dans le système de contrôle de version (Git). C'est pourquoi il existe des fichiers .env qui sont ajoutés au .gitignore.

Quiz pour la consolidation

1. Pour se protéger de l'interception de données sur les réseaux publics, on utilise :

2. La limitation du taux de requêtes (Rate Limiting) protège principalement contre :

3. La question "Qu'est-ce que cet utilisateur a le droit de faire ?" est résolue par :

4. Les clés secrètes d'API et les mots de passe de la base de données doivent être stockés :

🚀 Fin du cours Félicitations, commandant ! Vous avez mené à bien toutes les missions.

Vous êtes passé d'un débutant qui n'avait qu'entendu parler des API à un ingénieur capable de concevoir, développer, documenter, sécuriser et tester de manière autonome un service web complet en utilisant deux des technologies les plus populaires de leurs écosystèmes respectifs.

Vous avez maîtrisé le langage universel REST, appris Laravel et FastAPI et construit pour eux un "Centre de Contrôle de Mission" en JavaScript pur.

C'est une énorme réussite. Le monde du développement API est désormais ouvert à vous. Continuez à explorer, à apprendre et à construire des choses incroyables.

Fin de la transmission. 🚀

☄ Soutenez la mission

La création de ce tutoriel — est un long et complexe voyage qui demande beaucoup de temps et d'énergie. Si ce contenu vous a été utile, vous pouvez nous aider à remplir les réservoirs de carburant de notre expédition. Chaque soutien est un tour de plus sur l'orbite vers de nouveaux matériaux utiles.

Buy Me a Coffee at ko-fi.com