Comment protéger votre API contre les accès non autorisés

Les API gèrent aujourd’hui 71 % de tout le trafic web, pourtant 78 % des attaques réussissent après l’authentification. Si vous vous fiez uniquement aux clés API ou à l’authentification de base, votre API reste vulnérable aux accès non autorisés, aux violations de données et aux interruptions de service.

Cet article couvre les pratiques de sécurité essentielles que tout développeur doit connaître : les méthodes d’authentification appropriées (JWT, OAuth 2.0), les contrôles d’autorisation (RBAC), la limitation du débit, la validation des entrées, le chiffrement et l’implémentation d’une passerelle API. Vous apprendrez à construire des défenses en couches qui fonctionnent ensemble pour prévenir les accès non autorisés—même lorsque les attaquants possèdent des identifiants valides.

Authentification : votre première ligne de défense

Authentification JWT pour une sécurité sans état

Les JSON Web Tokens (JWT) fournissent une authentification sans état idéale pour les systèmes distribués et les microservices. Contrairement à l’authentification basée sur les sessions, les JWT contiennent toutes les informations nécessaires dans le token lui-même.

// Generate JWT with proper security claims
const jwt = require('jsonwebtoken');

function generateToken(user) {
  return jwt.sign(
    {
      sub: user.id,
      scope: user.permissions,
      exp: Math.floor(Date.now() / 1000) + (15 * 60) // 15 minutes
    },
    process.env.JWT_SECRET,
    { algorithm: 'HS256' }
  );
}

Pratiques de sécurité critiques pour JWT :

• Définissez des délais d’expiration courts (15-30 minutes)
• Utilisez des secrets forts générés aléatoirement
• Validez l’algorithme explicitement pour prévenir les attaques par confusion d’algorithme
• Implémentez la rotation des tokens de rafraîchissement pour les sessions de longue durée

OAuth 2.0 pour l’accès tiers

OAuth 2.0 excelle lorsque vous avez besoin d’une autorisation déléguée—permettant aux applications tierces d’accéder à votre API sans partager les identifiants. Utilisez OAuth 2.0 avec l’extension PKCE (Proof Key for Code Exchange) pour les applications mobiles et les SPA afin de prévenir l’interception du code d’autorisation.

Autorisation : contrôler ce que les utilisateurs peuvent faire

Implémenter le contrôle d’accès basé sur les rôles (RBAC)

L’authentification vérifie l’identité ; l’autorisation détermine les permissions. Le RBAC attribue des permissions aux rôles plutôt qu’aux utilisateurs individuels, simplifiant ainsi la gestion des accès.

const permissions = {
  admin: ['read', 'write', 'delete'],
  editor: ['read', 'write'],
  viewer: ['read']
};

function authorize(requiredPermission) {
  return (req, res, next) => {
    const userPermissions = permissions[req.user.role];
    if (!userPermissions?.includes(requiredPermission)) {
      return res.status(403).json({ error: 'Insufficient permissions' });
    }
    next();
  };
}

Appliquez le principe du moindre privilège—n’accordez que l’accès minimum nécessaire pour chaque rôle.

Limitation du débit : prévenir les abus et les attaques DoS

La limitation du débit protège contre les attaques par force brute, les tentatives de DoS et l’épuisement des ressources. Implémentez des limites échelonnées basées sur les rôles utilisateurs ou les niveaux d’abonnement.

const rateLimit = require('express-rate-limit');

const limiter = rateLimit({
  windowMs: 60 * 1000, // 1 minute
  max: 100, // requests per window
  standardHeaders: true, // Return rate limit info in headers
  handler: (req, res) => {
    res.status(429).json({
      error: 'Too many requests',
      retryAfter: req.rateLimit.resetTime
    });
  }
});

Pour les systèmes distribués, utilisez Redis pour partager les compteurs de limitation du débit entre les instances.

Validation des entrées : stopper les attaques par injection

Ne faites jamais confiance aux entrées client. Validez toutes les données entrantes selon des schémas stricts pour prévenir les injections SQL, XSS et les attaques par injection de commandes.

const Ajv = require('ajv');
const ajv = new Ajv();

const userSchema = {
  type: 'object',
  properties: {
    email: { type: 'string', format: 'email' },
    age: { type: 'integer', minimum: 18, maximum: 120 }
  },
  required: ['email'],
  additionalProperties: false // Prevent mass assignment
};

const validate = ajv.compile(userSchema);

if (!validate(req.body)) {
  return res.status(400).json({ errors: validate.errors });
}

Chiffrement : protéger les données en transit

Toujours utiliser HTTPS/TLS

Imposez HTTPS pour tous les endpoints API—sans exception. Utilisez TLS 1.3 lorsque c’est possible et implémentez les en-têtes HTTP Strict Transport Security (HSTS) pour prévenir les attaques par rétrogradation.

app.use((req, res, next) => {
  res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
  next();
});

Sécurité de la passerelle API : protection centralisée

Une passerelle API comme Kong, AWS API Gateway ou Tyk fournit un point de contrôle unique pour les politiques de sécurité. Les passerelles gèrent :

• L’authentification et l’autorisation
• La limitation et le contrôle du débit
• La transformation des requêtes/réponses
• La journalisation et la surveillance
• La protection DDoS

Cette approche centralisée simplifie la gestion de la sécurité et garantit une application cohérente des politiques sur tous les endpoints.

Pièges de sécurité courants à éviter

Ne stockez jamais de secrets dans le code frontend. Les clés API, tokens et identifiants dans le JavaScript côté client sont visibles par quiconque inspecte le code.

Ne comptez pas uniquement sur CORS pour la sécurité. CORS empêche les navigateurs de faire des requêtes non autorisées mais ne protège pas contre les appels API directs depuis des outils comme Postman ou curl.

Évitez d’exposer directement les services internes. Routez toujours le trafic externe via une passerelle API ou un proxy inverse qui applique les politiques de sécurité.

N’utilisez pas de tokens à longue durée de vie sans rotation. Implémentez des mécanismes de rafraîchissement de tokens et invalidez les tokens lors de la déconnexion ou d’une activité suspecte.

Construire une sécurité API en couches

Aucune mesure de sécurité unique ne fournit une protection complète. Une sécurité API efficace nécessite plusieurs couches fonctionnant ensemble :

1. L’authentification vérifie l’identité
2. L’autorisation contrôle l’accès
3. La limitation du débit prévient les abus
4. La validation des entrées bloque les données malveillantes
5. Le chiffrement protège les données en transit
6. Les passerelles API centralisent les contrôles de sécurité

Chaque couche compense les faiblesses potentielles des autres. Lorsqu’un attaquant contourne une défense, la couche suivante l’arrête.

Conclusion

Protéger votre API contre les accès non autorisés nécessite plus que simplement ajouter une authentification. En implémentant l’authentification JWT ou OAuth 2.0, l’autorisation RBAC, la limitation du débit, la validation des entrées, le chiffrement HTTPS et la sécurité par passerelle API, vous créez un système de défense robuste qui protège contre les menaces externes et les risques internes.

Commencez par les bases—HTTPS, authentification et limitation du débit—puis ajoutez progressivement des couches en fonction de votre profil de risque. Rappelez-vous : la sécurité n’est pas une implémentation ponctuelle mais un processus continu qui évolue avec votre API et le paysage des menaces.

FAQ

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.