🔐 API Security – Découverte, protection, schémas, REST, GraphQL & WebSockets

Les risques typiques d'une API exposée

Checklist d'audit rapide

Détection des Shadow / Zombie APIs

Une Shadow API est une API active mais non inventoriée. Une Zombie API est une ancienne version encore accessible. Les deux augmentent le risque car elles échappent souvent aux contrôles de sécurité et au patch management.

Score de criticité API

risk_score = exposure_weight + data_sensitivity + action_impact + auth_weakness + traffic_anomaly

Example:
Public + PII + write + weak auth + unknown spec = Critical

Catalogue exploitable

Le résultat attendu n'est pas seulement une liste d'URLs, mais un inventaire exploitable par la sécurité, les équipes produit et l'exploitation.

Mapping vers contrôles runtime

Tests sécurité API par risque

BOLA test pattern
1. Créer deux comptes A et B
2. Récupérer un object_id valide depuis A
3. Réutiliser cet object_id avec le token de B
4. Attendu: 403 ou 404, jamais 200

Mass assignment test
PATCH /api/users/me
{
  "displayName": "test",
  "role": "admin",
  "isVerified": true
}
Attendu: champs role/isVerified ignorés ou rejetés

Priorisation réaliste

Headers importants pour API

Gestion des erreurs

Une API doit être diagnostiquable sans exposer stacktrace, SQL, chemins fichiers, détails de librairie ou secrets.

Bad response:
500 Internal Error: psycopg2.errors.SyntaxError at /var/app/db.py line 88

Good response:
{
  "error": "invalid_request",
  "message": "The request cannot be processed.",
  "correlation_id": "req_7f52a1",
  "status": 400
}

Cache et données sensibles

Contrôle strict du body

Détection de drift contrat/runtime

Le drift apparaît quand le trafic réel ne correspond plus au contrat documenté : nouveaux champs, routes inconnues, types différents, versions parallèles.

Déploiement progressif

Autorisation : route, fonction, objet, champ

Hygiène des tokens

• Access token court, refresh token rotatif.
• Scopes minimaux et lisibles.
• Pas de données sensibles inutiles dans les claims.
• Revocation ou introspection pour opérations critiques.
• Binding possible : mTLS-bound token ou DPoP selon architecture.

Example scopes:
orders:read
orders:write
orders:refund
users:read:self
users:read:any

Défaillances fréquentes

Limiter au bon niveau

Rate limit policy example:
- login: 5/min/IP + 20/h/account
- search: 60/min/token + max page_size 100
- export: 3/h/tenant + async job only
- payment: 10/min/token + idempotency key required

Rate limiting par coût

Pour GraphQL, compter les requêtes ne suffit pas : une seule query peut demander des milliers d'objets via profondeur, aliases et fragments.

Cost model idea:
base_cost = 1
field_cost = number_of_fields
list_cost = first/limit argument
nested_cost = depth_multiplier

Reject when:
depth > 8 OR complexity > 1000 OR aliases > 20

Réponses client propres

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

{
  "error": "rate_limit_exceeded",
  "message": "Too many requests. Retry later.",
  "correlation_id": "req_19ab"
}

Un bon rate limit protège la plateforme sans casser inutilement les intégrations légitimes.

Contrôles GraphQL essentiels

Autorisation au niveau champ

type User {
  id: ID!
  displayName: String!
  email: String!          # owner or admin only
  internalNotes: String   # support_admin only
  billingStatus: String   # billing scope only
}

Resolver rule:
if field == "email" and viewer.id != user.id and !viewer.hasRole("admin"):
    deny()

Observabilité GraphQL

Valider chaque message

Après l'upgrade HTTP, les messages WebSocket doivent être traités comme des entrées non fiables : type, taille, fréquence, schéma et autorisation doivent être contrôlés.

Message schema:
{
  "type": "subscribe_order",
  "request_id": "uuid",
  "payload": {
    "order_id": "ord_123"
  }
}

Controls:
- allowed message type
- max payload size
- JSON schema validation
- object-level authorization on order_id

Abus temps réel

Logs WebSocket utiles

On connect:
connection_id, user_id, tenant_id, origin, ip, user_agent

On message decision:
connection_id, message_type, object_id, decision, reason, latency_ms

On close:
connection_id, close_code, duration_sec, messages_in, messages_out

Contrôle backend obligatoire

def get_invoice(invoice_id, viewer):
    invoice = db.invoice.find_one({
        "id": invoice_id,
        "tenant_id": viewer.tenant_id
    })
    if not invoice:
        raise NotFound()
    if invoice.owner_id != viewer.user_id and not viewer.has_scope("invoice:read:any"):
        raise Forbidden()
    return invoice

Détection runtime BOLA

Réduire l'exposition

• Utiliser IDs non prédictibles, sans considérer cela comme une autorisation.
• Scoper les requêtes DB par tenant et owner dès le départ.
• Créer des ressources via collections de l'utilisateur : /me/orders/{id}.
• Éviter endpoints admin génériques exposés aux clients.
• Tester systématiquement avec deux comptes et deux tenants.

Mass assignment

Données sensibles

• Classer les champs : public, interne, personnel, secret, paiement.
• Masquer dans les logs : Authorization, cookies, tokens, secrets, cartes.
• Chiffrer ou tokeniser les données sensibles au repos.
• Appliquer minimisation : ne jamais renvoyer un champ inutile.
• Mettre en place data retention et purge.

Validation des réponses

La validation des réponses est souvent négligée, mais elle permet de détecter des fuites de champs internes après refactoring.

Response schema guard:
- additionalProperties: false
- deny fields matching: *password*, *secret*, *token*, *hash*
- max array size for list endpoints
- no stacktrace fields
- no internal service metadata

Positive security model

Au lieu de bloquer seulement ce qui ressemble à une attaque, on autorise uniquement ce qui correspond au contrat attendu.

Détection d'attaques applicatives

Examples of high-confidence blocks:
- SQLi patterns in string fields not expected to contain code
- XSS payloads in displayName/comment fields
- Command injection metacharacters in filename/host parameters
- SSRF attempts to 169.254.169.254 or internal ranges
- Path traversal in file download parameters
- JSON/XML bombs and oversized nested payloads

Anti-bypass

• Normaliser avant analyse : encoding, unicode, case, path normalization.
• Limiter content-types : JSON strict si API JSON.
• Refuser duplicate headers critiques ou paramètres ambigus.
• Traiter gzip/deflate avec limites de décompression.
• Bloquer HTTP request smuggling patterns côté edge.

Use-cases SOC API

Métriques de pilotage

Playbook incident API

Règles de lint OpenAPI

Fail build if:
- endpoint has no security requirement
- requestBody has no schema
- schema allows additionalProperties by default on sensitive endpoints
- string fields have no maxLength
- arrays have no maxItems
- 5xx response exposes stacktrace schema
- route has no owner or data classification

Fuzzing orienté API

• Types invalides : string au lieu de integer, null inattendu.
• Tailles extrêmes : champs trop longs, arrays massifs.
• Encodages : unicode, double encoding, path traversal.
• Business fuzzing : IDs d'autres utilisateurs, états workflow impossibles.
• GraphQL fuzzing : depth, aliases, fragments, introspection.

Policy as Code

api_policy:
  route: "POST /api/payments"
  auth:
    required: true
    scopes: ["payments:write"]
  limits:
    per_token: "10/min"
    per_tenant: "1000/day"
  schema:
    request: "#/components/schemas/CreatePayment"
    strict: true
  controls:
    require_idempotency_key: true
    log_decision: true

Ownership clair

• Chaque API a une équipe propriétaire.
• Chaque route critique a une classification de données.
• Chaque version a une date de fin de vie.
• Chaque exception WAAP a un ticket, une justification et une expiration.
• Les changements de spec passent par revue sécurité si endpoint sensible.

Indicateurs utiles

Pitch expertise API Security

Positionnement professionnel : capacité à sécuriser des APIs modernes de bout en bout, depuis l'inventaire et la modélisation des risques jusqu'à la protection runtime et l'intégration DevSecOps.

Je sais mettre en place une démarche API Security complète : découverte des APIs exposées, détection de shadow APIs, validation OpenAPI/JSON Schema, protection REST/GraphQL/WebSockets, contrôles OAuth2/OIDC/JWT/mTLS, rate limiting par token/tenant, détection BOLA/IDOR, intégration WAAP/API Gateway et observabilité SOC avec logs exploitables.