Sécurité REST : les bases - Guide complet d'hardening

Les API REST représentent encore en 2026 la grande majorité des API exposées - plus de 80 % du trafic API selon Postman State of API 2024. Leur maturité les rend à la fois bien documentées et massivement attaquées. Ce guide couvre les fondamentaux de sécurité pour API REST : conventions HTTP, authentification, CORS, TLS, validation d'entrée, rate limiting, pièges REST-spécifiques (verb tampering, HPP, method override) et checklist pratique. Complémentaire aux articles dédiés OWASP API Top 10, JWT et autorisation.

1. Rappel - qu'est-ce qu'une API REST

1.1 Les 6 contraintes de REST (Roy Fielding, 2000)

REST (REpresentational State Transfer) est un style architectural défini par Roy Fielding dans sa thèse de doctorat. Pas un protocole, un ensemble de contraintes :

1. Client-server : séparation stricte des responsabilités.
2. Stateless : chaque requête contient toute l'information nécessaire, pas d'état serveur entre deux requêtes.
3. Cacheable : les réponses doivent indiquer si elles sont cacheables.
4. Uniform interface : ressources identifiées par URI, manipulation via représentations, messages auto-descriptifs, HATEOAS.
5. Layered system : proxies, caches, gateways transparents.
6. Code on demand (optionnel) : le serveur peut envoyer du code exécutable au client.

La plupart des "API REST" en production respectent 3-4 contraintes sur 6. Strictement parlant, ce sont des HTTP APIs ou RESTful APIs. L'appellation REST est utilisée par convention.

1.2 Implications sécurité des contraintes

• Stateless : chaque requête doit être authentifiée indépendamment. Pas de "je te fais confiance parce que tu étais là la requête précédente".
• Cacheable : les données sensibles doivent explicitement déclarer Cache-Control: no-store pour ne pas se retrouver en cache proxy ou CDN.
• URI identifie ressources : les IDs exposés dans l'URI sont des cibles BOLA évidentes.
• Uniform interface : la surface d'attaque est prévisible, ce qui facilite le test - et l'attaque.

2. HTTP Methods - sémantique et sécurité

2.1 Les verbes principaux

• Safe : la méthode ne modifie aucune ressource côté serveur.
• Idempotent : plusieurs appels identiques ont le même effet qu'un seul.

2.2 GET ne doit jamais modifier

Erreur classique : GET /api/delete-user?id=123 qui supprime l'utilisateur 123.

Problèmes :

• Les crawlers web (Google, linters web, pré-cache browser) appellent GET sans vergogne → suppression accidentelle massive.
• Les requêtes GET sont loguées dans les access logs avec leurs paramètres query → fuite des actions dans les logs.
• CSRF triviale : un lien dans un email <img src="https://api.example.com/api/delete-user?id=victim"> exécute la suppression au chargement de l'email.
• Les Content Security Policies se concentrent sur POST, les GET destructifs passent souvent sous le radar.

Règle : GET = lecture seule. Tout effet de bord doit être sur POST/PUT/PATCH/DELETE.

2.3 Verb tampering

Attaque consistant à utiliser une méthode HTTP différente pour contourner les contrôles.

Exemple : l'application protège POST /api/admin/delete-user avec un middleware admin, mais accepte aussi DELETE /api/admin/delete-user sur la même route sans contrôle parce que la route générique accepte toutes les méthodes.

Mitigation : routes strictement typées par méthode (Express router.post(...), FastAPI @app.post(...)), tout appel avec une méthode non déclarée retourne 405 Method Not Allowed.

2.4 X-HTTP-Method-Override

Certains proxies d'entreprise limitent les méthodes HTTP à GET/POST. Des frameworks acceptent alors un header X-HTTP-Method-Override: DELETE pour simuler DELETE sur un POST.

Piège : si le WAF ne contrôle que la méthode "native" (POST) et pas l'override, un attaquant contourne les règles WAF.

Mitigation : désactiver le support X-HTTP-Method-Override sauf besoin explicite, et l'appliquer avant les contrôles sécurité.

2.5 HTTP PATCH et idempotence

PATCH n'est pas idempotent par défaut : PATCH /users/123 avec {"score": "+10"} incrémente le score. Deux appels = score +20.

Conséquence sécurité : en cas de retry network, risque de double application. Si l'effet de bord est critique (paiement, transfert), implémenter un mécanisme d'idempotency key :

POST /api/payments
Idempotency-Key: 7b3f8a-unique-per-transaction

Le serveur stocke la clé, les appels ultérieurs avec même clé retournent le résultat initial sans répéter l'effet.

3. Status codes - choisir sans fuiter d'info

3.1 Catégories standard

• 2xx Success : OK.
• 3xx Redirection : à manipuler prudemment (risque open redirect).
• 4xx Client error : erreur côté client, pas de retry utile.
• 5xx Server error : erreur côté serveur, retry potentiellement utile.

3.2 Status codes importants en sécurité

3.3 Le piège 401 vs 404 pour prévenir l'énumération

Endpoint GET /api/users/{email} :

• Si email existe : retourne 200 avec données → révèle l'existence.
• Si email n'existe pas : retourne 404.

Un attaquant teste des emails et distingue les existants des inexistants par le status code. Fuite de base de contacts.

Mitigation :

• Toujours même status code (404 ou 403) quel que soit le cas.
• Toujours même body générique.
• Timing constant : pas de différence de latence entre cas (utiliser des comparaisons constant-time si check DB sensible).

3.4 Messages d'erreur - pas de fuite

Mauvais :

500 Internal Server Error
{
  "error": "SQLException: ORA-00942: table or view does not exist at com.example.UserRepo.findById(UserRepo.java:42)"
}

Bon :

500 Internal Server Error
{
  "error": "Internal server error",
  "request_id": "req_a1b2c3d4"
}

L'ID de requête permet au support de retrouver les détails dans les logs internes sans exposer au client.

4. Authentification - patterns REST

4.1 Bearer token (JWT ou opaque)

Pattern dominant en 2026 :

GET /api/users/me
Authorization: Bearer eyJhbGciOi...

• JWT : voir JWT risques et bonnes pratiques.
• Opaque tokens : string aléatoire, validation par lookup DB/Redis. Meilleure révocabilité.

4.2 mTLS (mutual TLS)

Chaque client présente un certificat X.509 au serveur. Usage : machine-to-machine, partenaires B2B critiques.

GET /api/internal/payments
[handshake mTLS avec cert client]

Avantages : pas de secret transmis à chaque requête, rotation possible via PKI, pas de risque de token volé.

Inconvénients : setup plus lourd, gestion de la PKI.

4.3 API keys

String statique émise au client. Transportée :

• Header custom : X-API-Key: <key> — préféré.
• Header Authorization : Authorization: ApiKey <key> — acceptable.
• Query parameter : ?api_key=<key> — à bannir (loggé dans access logs, historique navigateur).

Limites :

• Généralement pas liée à un user spécifique.
• Rotation difficile si key distribuée à plusieurs clients.
• Compromission = accès illimité jusqu'à rotation.

Usage recommandé : M2M simple, quotas, partenaires low-sensitivity. Pour auth utilisateur, préférer OAuth + tokens courts.

4.4 Basic Auth

Authorization: Basic <base64(user:pass)> — credentials en clair (base64 = pas du chiffrement).

Usage acceptable uniquement :

• Via HTTPS strict (jamais sur HTTP).
• Scénarios internes avec rotation fréquente.
• APIs low-sensitivity.

Déconseillé pour les nouvelles APIs publiques en 2026. Préférer Bearer tokens.

4.5 Session cookie

Pour API servant un frontend same-origin (SPA hébergée sur le même domaine que l'API), les session cookies peuvent remplacer les Bearer tokens avec avantages :

• Cookies HttpOnly non accessibles au JS → protection XSS.
• Secure → pas transmis en HTTP.
• SameSite=Strict → protection CSRF.

Limite : seulement pour same-origin, pas pour APIs appelées par multiples clients cross-origin.

5. TLS et chiffrement en transit

5.1 TLS obligatoire partout

En 2026, HTTPS pour toute API en production n'est plus négociable :

• TLS 1.2 minimum, idéalement TLS 1.3.
• Cipher suites modernes uniquement (pas RC4, 3DES, DES, MD5).
• Perfect Forward Secrecy obligatoire.
• Certificat valide émis par CA de confiance (Let's Encrypt pour la majorité, pas de certs self-signed en prod).

5.2 HSTS (HTTP Strict Transport Security)

Header serveur qui force le navigateur/client à utiliser HTTPS :

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

• max-age : durée en secondes (2 ans ici).
• includeSubDomains : couvre tous les sous-domaines.
• preload : inclus dans la HSTS preload list des navigateurs.

Voir security headers complet pour les détails.

5.3 Certificate pinning (mobile)

Les applications mobiles devraient pinner les certificats ou la clé publique de l'API pour empêcher le MITM par certificat frauduleux.

Deux approches :

• Certificate pinning : pinner le cert lui-même. Plus strict mais casse à chaque renouvellement.
• Public key pinning : pinner la clé publique. Plus résilient aux renouvellements.

Bibliothèques : OkHttp CertificatePinner (Android), URLSessionDelegate (iOS), TrustKit (both).

Attention : un pinning mal géré casse l'app quand on roule le cert. Avoir toujours un backup pin et un plan de rotation.

5.4 mTLS pour liens critiques

Communications entre services internes sensibles, partenaires B2B : mTLS obligatoire. Le certificat client prouve l'identité, pas de secret à transmettre.

6. CORS - Cross-Origin Resource Sharing

6.1 Le problème que CORS résout

Par défaut, un navigateur empêche le JS de https://app.example.com de lire les réponses d'https://api.other-company.com (Same-Origin Policy). CORS permet au serveur d'autoriser explicitement ces appels cross-origin.

6.2 Configuration classique

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 3600

6.3 Les erreurs CORS classiques

CORS trop permissif :

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Si Allow-Origin: *, le navigateur refuse les credentials (cookies). Mais certaines apps tombent dans la variante :

Access-Control-Allow-Origin: <reflect request Origin>
Access-Control-Allow-Credentials: true

Le serveur reflète le header Origin de la requête. Tout site peut faire des appels autorisés avec credentials. Fuite garantie.

6.4 CORS ne remplace pas l'autorisation

CORS contrôle quel JS du navigateur peut lire la réponse. Mais n'importe quel client HTTP (curl, Postman, script backend) ignore CORS et peut appeler l'API directement.

Règle : CORS est une protection navigateur, pas une authN/authZ. Les vraies protections (Bearer, mTLS, autorisation) doivent être en place indépendamment.

6.5 Configuration recommandée

• Allowlist stricte des origins : liste explicite, pas de wildcard sur les APIs avec credentials.
• Methods et Headers minimaux : seulement ceux effectivement utilisés.
• Credentials: true uniquement si nécessaire : réfléchir si vraiment besoin.
• Max-Age modéré : 600-3600 secondes, pas 86400+.

7. Input validation - schemas stricts

7.1 JSON Schema validation

Chaque endpoint doit valider le body contre un schéma JSON explicite :

from pydantic import BaseModel, EmailStr, Field, ConfigDict
 
class CreateOrderDTO(BaseModel):
    model_config = ConfigDict(extra="forbid")
    customer_email: EmailStr
    product_id: int = Field(gt=0)
    quantity: int = Field(gt=0, le=1000)
    shipping_address: str = Field(min_length=10, max_length=500)

Bénéfices :

• Rejet automatique des champs non prévus (Mass Assignment).
• Validation des types et contraintes.
• Documentation automatique (OpenAPI).

7.2 Validation en profondeur

• Length / size limits sur chaque champ string.
• Enum values pour champs à valeurs fixes.
• Regex patterns pour formats spécifiques (codes postaux, IBAN, etc.).
• Range pour numériques.
• Array item limits (max 100 elements par array, par ex.).
• Nested object depth limits.

7.3 Content-Type stricte

Vérifier le Content-Type attendu :

• Rejeter 415 Unsupported Media Type si application/xml est envoyé sur endpoint qui attend application/json.
• Ne jamais parser auto selon ce que dit Content-Type (risque de confusion).

7.4 Body size limits

Limites au niveau :

• Reverse proxy (nginx client_max_body_size).
• Application (frameworks ont généralement un default, à vérifier).
• Par endpoint si upload spécifique.

Limite typique : 1 MB pour JSON standard, 10 MB pour uploads documents, 100 MB+ pour uploads fichiers volumineux (video, backup).

7.5 Pièges HTTP Parameter Pollution (HPP)

Un même paramètre envoyé plusieurs fois :

GET /api/search?role=user&role=admin

Comportement selon framework :

• Express : req.query.role = ["user", "admin"] (array).
• Flask : request.args.get('role') = "user" (first), getlist('role') = les deux.
• Certains WAF : ne checkent que le premier, laissent passer le second.

Conséquence : si le WAF bloque role=admin mais laisse passer role=user&role=admin, l'attaquant peut injecter le second.

Mitigation : normaliser les paramètres avant validation (rejeter si duplicatas inattendus).

8. Rate limiting et quotas

8.1 Rate limiting multi-niveaux

Limites à appliquer en parallèle :

• Par IP : anti-DDoS basique, 1000 req/min par IP.
• Par user authentifié : anti-abuse, 100 req/min par user.
• Par endpoint : endpoints coûteux (search, export) limités plus strictement.
• Par API key / tenant : quotas business.

8.2 Algorithmes

• Fixed window : X requêtes par minute/heure. Simple mais autorise bursts en bord de fenêtre.
• Sliding window : fenêtre glissante. Plus précis, plus coûteux.
• Token bucket : tokens régénérés à taux constant. Autorise bursts puis throttle.
• Leaky bucket : similaire token bucket.

Implémentations : Redis (INCR + EXPIRE), nginx module, API gateways (Kong, Apigee), services managés (Cloudflare, AWS WAF).

8.3 Réponse 429 propre

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1719999999

{
  "error": "rate_limit_exceeded",
  "message": "Too many requests. Retry after 60 seconds.",
  "request_id": "req_abc123"
}

8.4 Rate limiting adaptatif et anti-bot

Le rate limiting basique ne suffit pas contre :

• Scraping progressif à 5 req/s pendant 3 mois depuis IPs rotatives.
• Credential stuffing distribué sur 10 000 IPs.

Solutions spécialisées : DataDome, Cloudflare Bot Management, Imperva Advanced Bot Protection, Akamai Bot Manager. Voir pourquoi les API sont attaquées pour le contexte.

9. Caching - implications sécurité

9.1 Risques de cache

• Cache sensible public : une réponse contenant des données utilisateur cachée dans un CDN edge partagé → leakée à d'autres utilisateurs.
• Cache en proxies intermédiaires : même problème.

9.2 Headers recommandés pour réponses sensibles

Cache-Control: no-store, no-cache, must-revalidate, private
Pragma: no-cache
Expires: 0

• no-store : ne pas stocker du tout.
• no-cache : peut stocker mais doit revalider à chaque usage.
• private : caches utilisateur OK, caches partagés non.

9.3 Vary header pour cache correct

Vary: Authorization

Indique que le cache doit être distinct par valeur du header Authorization. Sans ça, un cache proxy peut servir la réponse de user A à user B.

9.4 Cache des réponses d'erreur

Attention : 404 Not Found ou 429 Too Many Requests peuvent être cachés par défaut dans certains CDNs. Problème si la ressource devient accessible plus tard ou si la limite passe.

10. Pièges REST spécifiques

10.1 Open redirect via Location header

Endpoint :

GET /api/redirect?target=...

Si le serveur fait Location: $target sans validation, un attaquant fait :

GET /api/redirect?target=https://phishing.example

Mitigation : allowlist des targets autorisés, jamais de redirect vers URL arbitraire en input.

10.2 CRLF injection dans headers

Si un paramètre user est reflété dans un header HTTP sans sanitization, l'injection de \r\n permet d'injecter des headers arbitraires, parfois du body.

Mitigation : frameworks modernes sanitizent automatiquement, mais vérifier.

10.3 Content-Type confusion

API qui répond avec Content-Type: text/html au lieu de application/json pour une erreur → le navigateur peut interpréter une réponse contenant du HTML injecté (XSS via API).

Mitigation : toujours Content-Type: application/json strict + header X-Content-Type-Options: nosniff.

10.4 HTTP/2 smuggling

Vulnérabilités où des requêtes HTTP/1 et HTTP/2 sont interprétées différemment par front et back proxy, permettant à un attaquant d'injecter des requêtes invisibles. CVE-2023-series et PortSwigger research.

Mitigation : HTTP/2 end-to-end, versions à jour des proxies, hardening.

10.5 Race conditions

Un endpoint qui fait check + action en deux étapes est race-conditionable :

if user.credits > 0:
    user.credits -= 1
    grant_feature()

Deux appels simultanés passent le check avant modification. Mitigation : atomique DB-level (SQL UPDATE conditional, Redis atomic ops).

11. Versioning sécurisé

11.1 Approches de versioning

• URL : /v1/users, /v2/users — le plus lisible.
• Header Accept : Accept: application/vnd.api.v2+json — plus propre mais moins visible.
• Header custom : X-API-Version: 2 — non standard.
• Query param : ?v=2 — déconseillé (loggé en clair).

11.2 Vieilles versions = dette sécurité

Chaque version active = surface d'attaque supplémentaire. Les vieilles versions sont souvent moins maintenues, avec des vulnérabilités non corrigées.

Discipline :

• Deprecation annoncée avec date précise.
• Retrait effectif à date prévue, sans extension.
• Tests de régression sécurité sur toutes les versions actives.

11.3 Désactivation progressive

1. Ajout d'un header Deprecation: true + Sunset: <date> sur les réponses v1.
2. Warning dans les logs et notifications aux consommateurs.
3. 3 à 6 mois de deprecation.
4. Retrait effectif, retour 410 Gone.

12. Documentation et inventaire

12.1 OpenAPI (ex-Swagger)

Fichier YAML/JSON qui décrit tous les endpoints, méthodes, inputs, outputs, auth. Double usage :

• Friendly : doc interactive (Swagger UI, Redoc).
• Security : linting automatique (Spectral, 42Crunch), tests automatisés (Schemathesis), WAAP runtime qui apprend le schéma.

12.2 Inventaire central

Ne pas avoir un fichier OpenAPI par application dispersé - un registre central :

• API Gateway Developer Portal (Kong, Apigee).
• Postman Network interne.
• Backstage + TechDocs.
• Custom registry Git-based.

L'inventaire est la première défense contre les shadow APIs (API9:2023 Improper Inventory).

12.3 Deprecation et changelog

Chaque changement breaking doit être :

• Documenté avec date et impact.
• Communiqué aux consommateurs.
• Annoncé avec préavis adapté (30 jours minimum pour APIs internes, 6+ mois pour APIs publiques).

13. Outils de test et pentest REST

13.1 Tests en CI

• Schemathesis : fuzzing basé sur OpenAPI, génère des milliers de cas.
• 42Crunch CLI : linting sécurité de l'OpenAPI + tests de conformité.
• Postman Collection Runner : tests de contrat exécutables en CI.
• Dredd : teste l'implémentation contre l'OpenAPI.

13.2 Pentest manuel

• Burp Suite + extensions : JSON-Web-Tokens, HackBar, Autorize (tests BOLA automatisés).
• Postman : exploration manuelle et scripts de test.
• curl / httpie : tests rapides, scripts.
• Insomnia : alternative Postman.

13.3 DAST automatisé

• OWASP ZAP avec plugin API (OpenAPI import).
• Akto : open source discovery + testing.
• StackHawk : DAST CI-friendly.

13.4 Spécialistes API security

Salt Security, Noname (Akamai), Traceable, Wallarm, 42Crunch, Cequence : plateformes commerciales dédiées avec runtime testing, anomaly detection, discovery.

14. Checklist pratique REST hardening

Avant mise en production, vérifier :

Routing et méthodes

• Une route = une méthode HTTP explicite, 405 sur les autres
• GET strictement en lecture seule
• X-HTTP-Method-Override désactivé par défaut
• Idempotency key sur opérations critiques

Status codes et erreurs

• Pas de stack traces dans les réponses production
• 401 vs 404 unifié pour prévenir énumération
• Request ID dans chaque réponse pour traçabilité
• Messages d'erreur génériques

Auth et sessions

• Bearer token ou mTLS standard
• JWT validé strictement (voir JWT risques)
• API keys jamais en query params
• Session cookies HttpOnly Secure SameSite=Strict

TLS

• TLS 1.2+ obligatoire
• HSTS avec includeSubDomains et preload
• Certificate pinning sur clients mobiles
• mTLS pour B2B critique

CORS

• Allowlist stricte des origins, pas de wildcard avec credentials
• Methods et Headers minimaux
• Max-Age modéré

Input validation

• JSON schema strict avec extra=forbid
• Size limits par champ et par body
• Content-Type validé
• HPP handled

Autorisation

• Object-level check systématique (BOLA)
• Function-level check avec middleware admin (BFLA)
• Property-level via DTO et serializers (BOPLA)
• Tests automatisés 2+ users en CI

Rate limiting et quotas

• Multi-niveaux (IP, user, endpoint, tenant)
• Réponse 429 avec Retry-After
• Bot management sur flows sensibles

Caching

• Cache-Control: no-store sur données sensibles
• Vary: Authorization
• Pas de caching de 401/403/404 long

Versioning

• Versioning clair en URL ou header
• Deprecation process formalisé
• Pas plus de 2 versions actives simultanément

Documentation et inventaire

• OpenAPI à jour et versionnée
• Registre central
• Pas de shadow/zombie API

Observabilité

• Logs structurés par endpoint
• Pas de tokens en clair dans les logs
• Alertes sur patterns anormaux (volumes, 401 massifs, 5xx)

15. Verdict et posture Zeroday

Les fondamentaux REST n'ont pas beaucoup changé depuis 10 ans : HTTP bien utilisé, validation stricte, auth correcte, CORS prudent. Ce qui change, c'est le volume (explosion des APIs), le niveau de sophistication des attaquants (bots, IA, exploitation automatisée), et la reconnaissance que les défenses classiques (WAF) ne suffisent plus.

Pour un développeur : les 15 points de la checklist ci-dessus sont la compétence minimale attendue sur tout rôle back-end 2026. Les maîtriser produit une API qui ne finit pas en incident majeur.

Pour un AppSec : auditer ses APIs existantes contre cette checklist révèle généralement 30 à 50 % de non-conformités sur les applications développées avant la montée en maturité API security (avant 2022).

Pour une organisation : formaliser une API security checklist interne basée sur celle-ci, l'embarquer dans les revues PR et dans les audits périodiques, construit une baseline mesurable et démontrable aux auditeurs (SOC 2, ISO 27001, DORA).

Pour approfondir : pourquoi les API sont attaquées pour le contexte stratégique, OWASP API Security Top 10 expliqué pour les vulnérabilités par numéro, autorisation d'API : les bases pour la couche autorisation, JWT : risques et bonnes pratiques pour la brique d'authentification, security headers complet pour la couche HTTP transverse.