🛡️ WAF / WAAP – Protection applicative, OWASP Top 10 & API Security

Traitement d’une requête HTTP par un WAF / WAAP

Indicateurs à collecter dans les logs WAF / WAAP

timestamp=2026-07-06T14:21:09Z
client_ip=203.0.113.50
method=POST
host=app.example.com
uri=/api/v1/orders
status=403
rule_id=942100
rule_group=SQLI
anomaly_score=12
action=blocked
bot_score=18
trace_id=req-7fd4d1
upstream_status=-
reason="SQL injection pattern in parameter q"

Prioriser les règles selon l’exposition réelle

# Exemple de logique de priorisation
risk_score = exposure * exploitability * business_impact * confidence
if endpoint == "login" and failed_attempts_per_ip > threshold:
    action = "challenge_or_throttle"
if rule_group in ["SQLI", "RCE"] and anomaly_score >= 8:
    action = "block"

Les limites à assumer explicitement

Virtual patching : réduire l’exposition avant correction applicative

Lorsqu’une vulnérabilité est identifiée en production, une règle WAF ciblée peut bloquer l’exploitation pendant que l’équipe corrige le code, teste et déploie. Cela ne remplace pas le patch, mais réduit la fenêtre d’exposition.

# Pseudo-règle ciblée
IF uri == "/legacy/report" AND method == "GET" AND args["filter"] matches suspicious_sql_pattern
THEN block WITH reason="virtual_patch_legacy_report_sqli"

Réduire les faux positifs sans ouvrir la porte

Durcissement navigateur complémentaire

La Content Security Policy et les headers de sécurité limitent l’impact d’un XSS qui passerait malgré le WAF. Le WAAP peut injecter ou vérifier certains headers, mais l’idéal est de les gérer au niveau applicatif avec une politique cohérente.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax

Cas particulier des SPA React/Vue/Angular

Détection comportementale utile

IF endpoint matches "/api/invoices/{id}"
AND distinct_path_ids_per_user_5min > 30
AND error_ratio_403_404 > 0.45
THEN action = challenge_or_block
reason = "possible_id_enumeration"

Réduire BOLA et mass assignment par schéma

Un WAAP moderne peut utiliser OpenAPI/JSON Schema pour refuser des paramètres et champs inattendus. Cela ne prouve pas l’autorisation, mais empêche de nombreuses manipulations opportunistes.

# Exemple de champ interdit détecté
method=PATCH uri=/api/users/me
json_field="role"
expected_schema="UserSelfUpdate"
action=blocked
reason="unexpected_sensitive_field"

Contrôles indispensables côté backend

• Autorisation objet par objet : vérifier l’appartenance de chaque ressource côté serveur.
• RBAC/ABAC : centraliser les décisions, éviter les if dispersés.
• IDs non devinables : UUID ou opaque IDs ne remplacent pas l’autorisation mais réduisent l’énumération.
• Tests de sécurité : scénarios user A / user B automatisés.
• Journalisation métier : événement d’accès refusé avec ressource et sujet pseudonymisés.

GraphQL : surface compacte, risque concentré

GraphQL expose souvent un seul endpoint HTTP, mais la complexité est dans la query. Le WAAP doit comprendre profondeur, coût, introspection, fragments, aliases et mutations sensibles.

graphql.max_depth = 8
graphql.max_aliases = 20
graphql.block_introspection = true
graphql.require_auth_for_mutations = true

Abus métier des APIs

HTTP Request Smuggling / Desynchronization

Le request smuggling exploite des différences d’interprétation entre composants HTTP : CDN, WAF, reverse proxy, serveur applicatif. La défense est surtout une politique stricte sur framing, headers et versions HTTP.

Path traversal et signaux SSRF

# Signaux à surveiller
args.url contains "http://169.254.169.254"
args.path contains encoded_traversal
host header != expected_host
redirect_uri domain not in allowlist

Uploads : surface critique

IF uri == "/upload/avatar"
AND NOT file.extension IN ["jpg", "png", "webp"]
THEN block

IF file.size > 5MB THEN block
IF file.mime != detected_mime THEN quarantine

Protection du login

Le credential stuffing utilise des couples login/mot de passe compromis sur d’autres services. L’attaque peut être lente, distribuée et apparemment normale par IP.

IF endpoint == "/login"
AND failed_logins_for_account_10min > 5
THEN require_mfa_or_delay

IF distinct_accounts_per_ip_5min > 20
THEN block_or_challenge

Détecter le scraping sans bloquer Google ni partenaires

Choisir le bon niveau de friction

risk = bot_score + reputation_score + velocity_score + endpoint_sensitivity
if risk < 30: action = "allow"
elif risk < 70: action = "challenge"
else: action = "block_or_mfa"

Rate limit multi-dimensionnel

/login      10 req/min/account
/search     60 req/min/session
/export     3 req/hour/user
/graphql    max_cost=1000/min/token
/api/order  20 req/min/user

Préserver le backend

# Principe réseau
origin firewall allow only:
  - WAAP edge IP ranges
  - deployment pipeline
  - admin VPN
block direct internet traffic to origin

Slowloris, slow POST, connexions lentes

Certaines attaques ne cherchent pas le débit, mais l’occupation de ressources : sockets, workers, buffers. Le WAF/reverse proxy doit imposer des timeouts et limites cohérentes.

Politiques par famille d’endpoints

IF uri startswith "/admin"
AND NOT client_ip IN trusted_admin_ranges
THEN block

Construire le modèle sans casser la production

Pièges du modèle positif

• Applications très dynamiques : routes et paramètres changent souvent ; le modèle dérive vite.
• Clients mobiles anciens : versions d’API non homogènes, formats historiques.
• Partenaires : intégrations B2B hors contrat ou mal documentées.
• GraphQL : un endpoint unique cache une grande variété de requêtes.
• Uploads : trop de contraintes peuvent bloquer des fichiers métiers légitimes.

Pipeline logique des règles

Exceptions : chirurgicales, temporaires, auditées

exception:
  route: /search
  parameter: q
  rule_id: 942100
  reason: "texte libre avec apostrophes légitimes"
  owner: "team-search"
  expires: "2026-09-01"

Gouverner les règles comme du code

• Versionning : chaque changement de policy doit être tracé.
• Review : double validation pour exceptions critiques.
• Staging : tester sur préproduction et replay de logs.
• Canary : appliquer d’abord à un pourcentage faible ou log-only.
• Metrics : faux positifs, blocages, top rules, latence.
• Expiration : toute exception doit avoir une date de revue.

Headers à contrôler ou injecter

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()
Content-Security-Policy: default-src 'self'; object-src 'none'; frame-ancestors 'none'

CORS : souvent mal compris

IF response.header["Access-Control-Allow-Origin"] == request.header["Origin"]
AND origin NOT IN cors_allowlist
THEN alert_or_strip_header

Durcissement des cookies

Dashboards utiles

KPIs hebdo:
- blocked_requests_by_category
- challenged_vs_solved
- false_positive_rate
- top_attacked_endpoints
- policy_exceptions_expiring
- mean_time_to_tune

Alertes à forte valeur

Reconstituer un incident applicatif

incident_query:
  trace_id: req-*
  src_ip: 203.0.113.50
  time_range: 2026-07-06T13:00Z..15:00Z
  rule_groups: [SQLI, RCE, XSS]
  include_upstream_5xx: true

Maîtriser les headers de chaîne

Le WAF doit savoir quelle IP est réellement le client. Une mauvaise confiance dans X-Forwarded-For peut permettre de contourner des contrôles par IP.

Client → CDN/WAAP → Load Balancer → Nginx → App

À sécuriser:
- trusted_proxy_ranges
- X-Forwarded-For overwrite au premier proxy de confiance
- X-Real-IP cohérent
- Forwarded header normalisé
- trace_id propagé

Fail-open vs fail-closed

WAAP dans Kubernetes

Checklist Kubernetes:
[ ] Services non exposés directement Internet
[ ] Ingress annoté avec policy WAF
[ ] OpenAPI versionnée
[ ] Logs ingress corrélés avec app trace_id
[ ] NetworkPolicy limite accès origine

Qui possède quoi ?

Mesurer la maturité

Roadmap de maturité WAAP