Sécurité API et filtrage des requêtes

1) Pourquoi est-ce nécessaire

L'API est la frontière externe et interne de la plate-forme. Toute erreur d'authentification, d'autorisation, de validation ou de normalisation des requêtes se transforme en exploitation des vulnérabilités (BOLA/IDOR, injection, SSRF, surcharge massive, épuisement des ressources). Objectif : créer une protection multi-niveaux (defense-in-depth) du périmètre aux règles commerciales, avec des SLO mesurables et un contrôle des risques.

2) Inventaire et classification de l'API

Répertoire API : registre de tous les services/endpoints, propriétaires, versions, types de clients (web, mobile, partenaires), mode (public/affilié/interne), PII/findness.
Criticité : High (transactions financières/autorisation), Medium (lecture du profil), Low (manuels publics).
Surface d'attaque : REST, GraphQL, gRPC, WebSocket, webhooks.
Statut : prod/staging/experimental, politique deprecate, durée de vie des tokens/clés.
Shadow/API abandonnées : détection par Ingrest logs, télémétrie eBPF/Service Mesh, comparaison avec le répertoire.

3) Modèle de menace (brièvement)

Identification : détournement de tokens, fixation de session, MitM, replay.
Autorisation : BOLA/IDOR, escalade horizontale/verticale.
Entrée : injections (SQL/NoSQL/LDAP), modèle/sérolyse, chemin de fer, en-têtes.
Trafic : DDoS/L7-fluds, requêtes lentes, retraits fantômes.
Intégrations : webhooks dangereux, SSRF via les paramètres URL, téléchargements de fichiers/scans.
Logique : abus de bonus, courses, incohérence de l'idempotence.

4) Norme de sécurité de base (minimum)

1. TLS 1. 2 + partout ; HSTS; Les codes faibles sont désactivés.
2. Authentification : OAuth2/OIDC pour les clients, mTLS/ou HMAC - service-k-service.
3. Autorisation : PDP centralisé (RBAC/ABAC), vérification au niveau objet (BOLA).
4. Validation : schéma strict (OpenAPI/JSON Schema/Protobuf), échec dans les champs superflus.
5. Limites : rate/quotas + burst, per-client/per-IP/per-token.
6. Idempotence sur les opérations de write, protection contre les répétitions/courses.
7. WAF/filtrage de jeu : normalisation des chemins/en-têtes, feuilles de deny, bloc payload-anti-patterns.
8. Secrets : KMS/Vault, rotation des clés/certificats, contrôle des fuites.
9. Observabilité : tracing, audit-logs de sécurité (qui/quoi/quand/résultat), alertes.
10. Procédures : playbook des incidents, tests et pentestes réguliers/DAST.

5) Authentification et gestion des tokens

OAuth2/OIDC : jetons d'accès à courte durée de vie, refresh strictement selon OIDC ; audience/issuer/bou sont vérifiés pour le gateway.
JWT: RS256/ES256; un ensemble minimum de clymes ; 'nbf/bou/aud'sont obligatoires ; interdiction de stocker des IPI. Rotation des clés via JWKS.
DPoP/PoP : lier le jeton à la clé du client pour réduire le risque de replay/vol.
mTLS pour les systèmes internes et les partenaires de confiance (certification CN/SAN, CRL/OCSP).
HMAC (signatures) : canonisation déterministe (méthode + chemin + timestamp + nonce + body-hash) ; fenêtre de temps valide (± 300s).
Sessions du navigateur : SameSite = strict/lax, HttpOnly, Secure ; protection CSRF (double submit/state tokens).
Stockage des clients : sur mobile - stockage sécurisé (Keychain/Keystore), protection contre les débris, pinning de certificats.

6) Autorisation (BOLA-first)

Object-level : chaque opération vérifie le droit à une ressource spécifique (ressource owner/scope/attributs).
RBAC/ABAC : rôles + attributs (pays, segment, limites de risque, niveau KYC).
Politiques : deny-by-default ; allow explicite ; Le versionage des politiques ; tests de cas négatifs.
Cache de solutions : TTL adaptative + handicap lorsque les rôles/segments changent.

7) Filtrage et normalisation des requêtes (sur gateway/WAF)

Normalisation : compression des slashs répétés, interdiction de '../', décodage une fois, recadrage des espaces/zéro-octets.
Titres : allow-list ('Host',' Content-Type ',' Accept ',' Autorisation ',' Date ',' Idempotency-Key ', les titres de trace souhaités).
Méthodes : 'GET/HEAD' sans corps ; 'POST/PUT/PATCH' avec le type 'application/json' ou strictement autorisé.
Dimensions : max-body, max-headers, max-path ; early-reject 413/431.
Fichiers : Validateur MIME, antivirus/sandbox, interdiction de contenu actif, récupération/assainissement des images.
Transfert URL/fatchi : bloc SSRF (deny private ranges/metadata IP, schéma « https » uniquement, allow-list des domaines).
Modèles SQL/NoSQL : signatures d'injection via WAF rule-sets + paramétrage serveur des requêtes.

Exemple de stratégie de titre (pseudo-format)

deny_headers: ["X-Forwarded-Proto","X-Original-URL","Proxy-Connection","Destination"]
require_headers: ["Authorization" (для protected), "Content-Type" (для write)]
strip_duplicates: true max_header_count: 32 max_header_size: 16KB

8) Limites, quotas et protection antibot

Rate limiting: token-bucket/ leaky-bucket; les niveaux sont per IP, per API key, per user, per org.
Quotas : journaliers/mensuels, séparés pour les méthodes write/expensive.
Adaptabilité : resserrement dynamique en cas d'anomalies (sudden burst/credential stuffing).
Slow-loris/slow-POST : temps de lecture/keep-alive, limitation des connexions parallèles.
Antibot : device-fingerprint, signes comportementaux, proof-of-work/captcha à haut risque, liste des réseaux thor/proxy.
Contrôle IP : filtres géo/ASN, feuilles deny des sous-réseaux « sales », feuilles allow pour les partenaires/panneau admin.

9) Validation des entrées et des schémas

Fail-closed : tout ce qui ne passe pas le circuit est 400. Les champs supplémentaires sont à rejeter.
Types/fourchettes : nombres, dates (UTC/ISO-8601), valeurs d'enum, longueurs de lignes, réglages.
Qualité JSON : max-nesting, interdiction des grands tableaux/clés, ordre canonique (facultatif).
Validation d'entreprise : idempotence selon 'Idempotency-Key' ; règles anti-frod (limites de fréquence des opérations, caps amount).
GraphQL : depth/complexity-limit, allow-listed queries, autorisation de champ.
gRPC : schémas Protobuf stricts, champs obligatoires, limites de taille des messages.

10) Webhooks et appels externes

Signatures : HMAC avec Timestamps/nonce ; vérification préalable au traitement ; fenêtre +/- 5 min.
Livraison : retraits avec pause exponentielle et jitter ; max-tentatives ; déduplication par ID d'événement.
IP allow-list du fournisseur ; un sous-domaine/chemin distinct ; pile d'hébergement minimale.
Réponses : 2xx seulement après un enregistrement interne réussi ; sinon 4xx/5xx avec un code compréhensible.
Contrôle SSRF sortant : avec callback URL - allow-list, interdiction des adresses privées.

11) Cryptage et gestion des secrets

Dans le canal : TLS 1. 2+/1. 3, pinning, politique de cryptage stricte.
Au repos : cryptage OBD/stockage objet, clés séparées pour PII/finddans.
KMS/Vault : stockage centralisé des secrets, TTL courts, rotation automatique.
Clés et certificats : distincts pour les environnements ; la vérification des émissions ; interdiction du retrait dans les logs.
Token-introspection : liste de révocation offline (revocation), courte « bou ».

12) Observation, audit et intervention

Logs de sécurité : tentatives/succès d'authentification, refus d'autorisation, événements rate-limit, changements de rôle/limites.
Trace : correlation-ID de bout en bout ; traçage des appels externes.
Métriques : RPS, P95/P99 latency, error-rate par code, proportion de 401/403/429, hit-rate limites, anomalies.
Alerties : surtensions de 401/403/429, croissance de 5xx, fréquents conflits d'idempotency, abruptes déviations du grapheQL-complexity.
Playbooks : verrouillage des clés/tokens, retour rapide des règles, échauffement de la feuille de deny, notification des propriétaires de services.
Forenzica : maintien d'un payload controversé (avec édition PII sécurisée), relais sur un stand isolé.

13) Erreurs et réponses au client

Format d'erreur unique (code, message, trace-id, catégorie).
Pas de fuites : ne pas révéler le SQL, les noms des tables, les aïeux internes ; 403 au lieu de « pourquoi pas ».
Codes : 400 (validation), 401 (pas d'authentification), 403 (pas de droits), 404 (masquer l'existence), 405/406, 413/429, 500/503.
Retry-Hints: для 429 — `Retry-After`; pour l'idempotence - conseil de répétition avec la même clé.

14) Modèles architecturaux

Zero-Trust : mTLS, autorisation explicite entre tous les services, privilèges minimums.
API-passerelle + WAF + service-mesh : partage des responsabilités - périmètre, politiques L7, authentification interne.
Canary/Blue-Green : lancer les nouvelles règles de filtrage par étapes avec observation.
Fail-closed : pour les writes critiques - mieux vaut refuser en toute sécurité que de permettre une opération incorrecte.
Backpressure : files d'attente/tampons, circuit breaker, timeouts/budgets.

15) Exemples de règles pratiques (pseudo-config)

15. 1 Limitation des voies et méthodes

/api/v1/payments:
allow_methods: [POST, GET]
auth: oauth2_required body:
content_type: application/json max_size: 256KB

15. 2 Idempotence

require_header: Idempotency-Key (UUIDv4)
store: redis:ttl=24h on_duplicate: return_previous_result

15. 3 Signature de la demande (HMAC)

signature:
scheme: "HMAC-SHA256"
required_headers: ["X-Signature","X-Timestamp","X-Nonce"]
allowed_drift: 300s string_to_sign: METHOD + "\n" + PATH + "\n" + SHA256(body) + "\n" + X-Timestamp + "\n" + X-Nonce

15. 4 SSRF Protection

outbound_http:
allowlist_domains: ["kyc. partner. com","psp. example. net"]
block_private_ip: true require_https: true

15. 5 GraphQL limite

graphql:
max_depth: 8 max_complexity: 500 allowlisted_operations_only: true

16) Spécificités d'iGaming/Finance

Limites sectorielles : dépendent du profil CUS/pays/risque.
Fenêtres temporelles : règles de fréquence des dépôts/retraits, « refroidir » entre les transactions.
Bonus anti-abyse : verrous constants sur le compte/appareil/IP/outil de paiement.
Audit des exigences réglementaires : stockage des logs d'action et de décision (KYC/AML), périodes de rétention, journaux invariables.

17) Liste de contrôle prod-ready

• Catalogue API complet et carte des flux de données (PII/finances marquées).
• OpenAPI/Protobuf schémas, tests de validation et contrats dans CI.
• mTLS/HMAC/OAuth2 configurés ; Des tokens TTL courts ; rotation des clés.
• Tests BOLA et cas négatifs d'autorisation ; PDP centralisé.
• Limites/quotas/anti-bot, protection contre le slow-loris ; Filtres IP.
• WAF/règles de normalisation du gateway, signatures anti-injection.
• L'idempotence des opérations d'écriture ; protection contre le replay.
• Webhook-signatures et allow-list ; endpoints isolés.
• Secrets dans KMS/Vault ; Les scoradges cryptés ; alerte sur les anomalies.
• Dashboards, alertes, logs d'audit ; les incidents de playbooks.
• Pentest régulier/DAST/SAST, pistes de vulnérabilités et patchs défectueux.

18) Antichambre (ce qui n'est pas possible)

Faites confiance à 'X-Forwarded-' sans terminaison TLS rigide sur votre périmètre.
Accepter les schémas « Content-Type » et « soft » JSON arbitraires.
JWT à longue durée de vie sans rappel/rotation.
Mélanger les rôles et les règles métiers dans un code sans règles centralisées.
Logs avec des secrets/PII ; les 500 messages détaillés vers l'extérieur.
Endpoints ouverts « temporaires » sans limites et sans autorisation.

19) Versioning et dépréciation

Versions dans le chemin/en-tête ; politiques de soutien (p. ex. N-2).
Annonces : délais de déprécation, surveillance de l'utilisation des anciennes versions, déconnexion gérée.
Interopérabilité : contrats et matrices de tests clients/partenaires.

20) Tests de sécurité

Tests contractuels de schémas/stratégies, entrées fuzzing, auth negative.
Profils de performance avec limites/quotas, test de protection (trafic chaos).
Red-team/bug-bounty : scripts BOLA, SSRF, signatures/relais, graphe QL-complexe.

TL; DR

1. Répertoire API + schémas stricts.
2. OAuth2/OIDC pour les clients, mTLS/HMAC à l'intérieur.
3. Périmètre BOLA par ressource (ABAC/RBAC).
4. Filtrage : normalisation des chemins/en-têtes, limites, règles WAF.
5. Idempotence, signatures, protection contre le replay/SSRF.
6. KMS/Vault et rotation des secrets.
7. Observabilité, alertes, playbooks.