🛡️ WAAP — Guide ULTRA — Web Application & API Protection

Menaces et dérives principales

• Confondre WAAP et firewall réseau : un WAAP inspecte le contexte HTTP/API, pas seulement IP/port/protocole.
• Activer un mode blocage global sans baselining peut casser des flux légitimes, surtout APIs et intégrations partenaires.
• Se reposer uniquement sur des signatures ignore les abus métier, les bots humains-assistés et les défauts d'autorisation.
• Ne pas synchroniser le WAAP avec l'inventaire API crée des angles morts : shadow APIs, versions oubliées, endpoints debug.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Méthode, URI normalisée, host, SNI, headers, cookies, user-agent, JA3/JA4 si disponible, ASN, pays, réputation IP.
• Content-Type, taille body, structure JSON/XML/form-data, champs inconnus, types inattendus, profondeur et cardinalité.
• Historique session/IP/device : rythme de requêtes, erreurs, séquences fonctionnelles, changement soudain de comportement.
• Corrélation WAF + API + bot + DDoS : un seul signal faible n'est pas toujours suffisant, l'agrégation réduit le bruit.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Politiques WAF managées et règles custom.
• Validation positive des APIs via schéma OpenAPI/GraphQL.
• Scoring bot, challenge progressif, allowlist partenaires, gestion des bons bots.
• Rate limiting par identité, endpoint, tenant, IP, token, clé API ou business flow.
• Protection DDoS L7 avec seuils adaptatifs, cache, tarpitting contrôlé, priorisation des clients authentifiés.

Actions graduées

Politique type

# Pseudo politique WAAP — Vue d'ensemble WAAP
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Vue d'ensemble WAAP
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Cartographier les applications et APIs exposées.
2. Classer endpoints publics, authentifiés, admin, partenaires et webhooks.
3. Activer observation, collecter baseline p95/p99 et top erreurs.
4. Activer règles haute confiance : protocol violations, signatures critiques, methods interdites.
5. Ajouter validation positive sur APIs stabilisées.
6. Connecter alertes WAAP au SOC avec contexte métier.
7. Revoir chaque exception toutes les deux semaines.

Rôles recommandés

Communication de crise

Incident WAAP — Vue d'ensemble WAAP
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Aucun endpoint critique exposé sans owner.
2. Tous les domaines passent par le point WAAP ou sont explicitement justifiés.
3. Mode blocage documenté par application.
4. Exceptions limitées dans le temps.
5. Dashboard par application, endpoint, risque et latence.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Penser qu'un WAF avec CRS suffit pour protéger une API sans schéma ni logique d'autorisation.
• Négliger les bons bots : moteurs de recherche, monitoring, partenaires, agrégateurs légitimes.
• Multiplier les produits ponctuels sans corrélation crée un SOC aveugle : chaque outil voit une pièce différente du puzzle.
• Migrer vers WAAP sans revisiter les règles historiques peut transporter des exceptions dangereuses.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Comparer requêtes web classiques et API : structure, authentification, volumes, endpoints coûteux, taux d'erreur.
• Identifier les routes où la sécurité négative est insuffisante et où une validation positive est possible.
• Mesurer les incidents impossibles à expliquer avec le WAF seul : abus métier, scraping faible bruit, credential stuffing distribué.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• WAF négatif : signatures, protocol violations, réputation.
• WAAP positif : schéma attendu, champs autorisés, types, méthodes et séquences valides.
• Bot management : fingerprint, comportement, challenge, réponse graduée.
• API governance : discovery, inventaire, drift detection, owner, criticité.

Actions graduées

Politique type

# Pseudo politique WAAP — WAAP vs WAF traditionnel
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — WAAP vs WAF traditionnel
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Lister règles WAF existantes et exceptions.
2. Identifier ce que le WAF ne sait pas : schéma, identité, business flow, bot score.
3. Activer modules API/bot/rate limiting par priorité de risque.
4. Réconcilier journaux WAF historiques et nouveaux événements WAAP.
5. Former SOC et développeurs aux nouveaux types d'alertes.

Rôles recommandés

Communication de crise

Incident WAAP — WAAP vs WAF traditionnel
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Table de correspondance WAF → WAAP établie.
2. Règles héritées nettoyées.
3. Différence monitor/challenge/block comprise par les équipes.
4. APIs classées par niveau de modèle positif possible.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Perdre l'adresse IP client réelle derrière plusieurs proxies.
• Déployer en fail-closed sans plan de secours peut provoquer une indisponibilité massive.
• Terminer TLS à un endroit non autorisé peut violer des contraintes de conformité.
• Avoir une politique différente par région ou cluster ouvre des contournements non intentionnels.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Topologie DNS, CNAME, certificats, SNI, origin shield, load balancers, ingress, routes internes.
• Chemin complet des headers : X-Forwarded-For, Forwarded, X-Request-ID, CF-Connecting-IP ou équivalent.
• Mesure latence avant/après WAAP par POP, région, application et type de client.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Mode proxy reverse avec terminaison TLS contrôlée.
• Mode edge/CDN pour filtrage précoce et absorption DDoS.
• Mode Kubernetes ingress avec politiques par namespace/application.
• Mode API gateway pour validation OpenAPI, JWT, quotas et plans consommateurs.
• Journalisation centralisée avec masquage des données sensibles.

Actions graduées

Politique type

# Pseudo politique WAAP — Architecture & déploiement
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Architecture & déploiement
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Dessiner le flux réel de bout en bout.
2. Valider TLS, IP client, headers et request-id.
3. Définir fail-open/fail-closed par application selon criticité.
4. Créer environnements staging et canary WAAP.
5. Tester rollback DNS/proxy/origin.
6. Documenter qui peut changer une politique et comment l'auditer.

Rôles recommandés

Communication de crise

Incident WAAP — Architecture & déploiement
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Schéma réseau validé.
2. Chaîne TLS comprise.
3. Failover testé.
4. Logs corrélés de l'edge à l'app.
5. Runbook DNS/proxy disponible.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Croire qu'un blocage injection corrige une injection dans le code.
• Ignorer Broken Access Control : beaucoup de BOLA/BFLA passent avec des requêtes syntaxiquement valides.
• Manquer la supply chain : dépendance vulnérable, image compromise, pipeline CI non sécurisé.
• Ne pas enrichir les événements WAAP avec logs applicatifs rend le mapping OWASP incomplet.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Tentatives de méthodes interdites, chemins sensibles, paramètres inattendus, erreurs applicatives répétées.
• Écarts d'autorisation : utilisateur normal appelant endpoint admin, IDOR suspect, changement de tenant ou d'organisation.
• Anomalies d'intégrité : callbacks inattendus, webhooks hors signature, artefacts inhabituels.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Règles managées OWASP et CRS.
• Contrôle d'accès complémentaire au niveau gateway : routes admin, IPs internes, headers signés.
• Validation positive des schémas et méthodes.
• Détection des erreurs 500 répétées sur payloads contrôlés.
• Corrélation avec SAST/DAST/SCA pour remédiation code.

Actions graduées

Politique type

# Pseudo politique WAAP — OWASP Top 10 Web 2025/2021
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — OWASP Top 10 Web 2025/2021
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Mapper chaque application aux catégories OWASP pertinentes.
2. Identifier ce qui est bloquable au WAAP et ce qui demande correction code.
3. Créer dashboard OWASP runtime par application.
4. Lier alertes WAAP aux tickets AppSec/Jira.
5. Revoir les endpoints A01/A07 avec tests d'autorisation automatisés.

Rôles recommandés

Communication de crise

Incident WAAP — OWASP Top 10 Web 2025/2021
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Mapping OWASP disponible.
2. Risque Broken Access Control traité hors WAAP aussi.
3. SCA/SBOM connecté à la gouvernance.
4. Événements logging/alerting suivis.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• BOLA : accéder à l'objet d'un autre utilisateur via un identifiant valide.
• BFLA : appeler une fonction administrative ou partenaire sans droit réel.
• Mass assignment : modifier un champ sensible non prévu par l'interface utilisateur.
• GraphQL coûteux : introspection non contrôlée, profondeur excessive, requêtes très chères.
• WebSockets : session longue, messages non validés, absence de quotas par canal.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Endpoint inconnu ou non documenté.
• Champ JSON absent du schéma ou type incorrect.
• Token valide mais comportement incohérent avec le rôle ou tenant.
• Explosion de cardinalité : IDs séquentiels, pagination excessive, requêtes GraphQL profondes.
• Taux de 401/403/404 élevé dans une même séquence.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Import OpenAPI et validation strict/loose par endpoint.
• Contrôle de methods, content-types, tailles et types de champs.
• GraphQL depth limit, complexity score, persisted queries, interdiction introspection en prod si non nécessaire.
• Quotas par client, token, organisation et plan commercial.
• Détection shadow APIs et versions orphelines.

Actions graduées

Politique type

# Pseudo politique WAAP — API Security
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — API Security
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Importer les spécifications OpenAPI existantes.
2. Découvrir automatiquement les endpoints non documentés.
3. Comparer trafic réel et schéma attendu.
4. Classer les écarts : erreur doc, évolution légitime, endpoint fantôme, attaque.
5. Activer blocage sur champs dangereux après validation.
6. Ajouter tests BOLA/BFLA côté CI.

Rôles recommandés

Communication de crise

Incident WAAP — API Security
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. OpenAPI à jour.
2. Endpoints non documentés revus.
3. GraphQL limité.
4. WebSockets supervisés.
5. Quotas par identité, pas seulement par IP.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• SQLi dans filtres de recherche, tris dynamiques, exports et endpoints admin.
• NoSQL injection dans opérateurs JSON mal filtrés.
• Command injection dans paramètres de fichiers, images, conversion, backup, diagnostics.
• LDAP/XPath/XML injection sur systèmes historiques.
• Faux positifs sur contenus légitimes : documentation, forum tech, payloads de tests internes.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Mots-clés ou opérateurs dangereux dans champs non prévus.
• Champs JSON contenant structures inattendues au lieu de scalaires.
• Erreurs SQL/DB corrélées à des requêtes bloquées ou suspectes.
• Réitération d'un même endpoint avec variations de payload.
• User-agent ou ASN associés à scanners automatisés.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Règles CRS/injection haute confiance.
• Validation positive type/format/longueur par champ.
• Normalisation encodage, content-type et parsing avant analyse.
• Blocage des commandes système dans entrées utilisateurs.
• Masquage logs pour ne pas stocker secrets ou payloads sensibles.

Actions graduées

Politique type

# Pseudo politique WAAP — Injections SQL/NoSQL/Command
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Injections SQL/NoSQL/Command
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Activer signatures injection en monitor.
2. Identifier endpoints générant faux positifs.
3. Ajouter règles positives sur champs structurés.
4. Coordonner avec développeurs pour requêtes paramétrées.
5. Créer tests DAST contrôlés sur staging.
6. Bloquer en production uniquement après validation des flux métiers.

Rôles recommandés

Communication de crise

Incident WAAP — Injections SQL/NoSQL/Command
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Paramétrage SQL côté code confirmé.
2. Champs dynamiques enumérés.
3. Règles haute confiance en blocage.
4. Faux positifs documentés et datés.
5. Logs DB corrélables aux événements WAAP.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• XSS stocké dans commentaires, profils, tickets support, contenus CMS.
• XSS réfléchi dans recherche, messages d'erreur, redirections.
• DOM XSS via fragments URL, postMessage, innerHTML, templates client.
• Exfiltration de tokens si cookies ou stockage local mal protégés.
• Dépendances front compromises ou tags marketing abusifs.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Présence de balises/script handlers dans paramètres textuels.
• Tentatives de protocole javascript: ou data: dans URLs.
• Changements anormaux de scripts tiers ou domaines chargés.
• CSP report-uri/report-to signalant violations inhabituelles.
• Taux élevé de payloads XSS sur formulaires publics.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Règles XSS managées.
• En-têtes sécurité : CSP, X-Content-Type-Options, Referrer-Policy, frame-ancestors.
• Challenge ou blocage sur payloads haute confiance.
• Monitoring client-side des scripts tiers si disponible.
• Protection cookies : Secure, HttpOnly, SameSite adaptés.

Actions graduées

Politique type

# Pseudo politique WAAP — XSS & sécurité côté client
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — XSS & sécurité côté client
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Identifier surfaces d'entrée utilisateur affichées ensuite.
2. Activer règles XSS en monitor puis blocage haute confiance.
3. Déployer CSP report-only puis enforcement.
4. Auditer cookies et stockage token côté client.
5. Créer tests front DOM XSS sur composants à risque.

Rôles recommandés

Communication de crise

Incident WAAP — XSS & sécurité côté client
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. CSP report-only analysée.
2. Cookies sécurisés.
3. Encodage contextuel côté app.
4. Aucun innerHTML non contrôlé.
5. Scripts tiers inventoriés.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Token absent, expiré, non signé correctement ou mauvais audience/issuer.
• Utilisateur standard accédant à route admin.
• Changement d'organisation/tenant dans path ou header.
• Clés API réutilisées depuis pays/ASN inattendus.
• Énumération de comptes par réponses de login différentes.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Taux de 401/403 élevé, variations d'ID, séquences login→MFA→échec répétées.
• Même token vu depuis multiples régions impossibles.
• Appels admin hors plage attendue ou sans mTLS.
• Changement rapide de tenant ou d'objet dans une session.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• JWT validation à la gateway : issuer, audience, expiry, algorithme, signature.
• mTLS pour partenaires et webhooks critiques.
• Rate limiting login/MFA/reset password par compte et IP.
• Blocage routes admin par contexte réseau/identité.
• Détection BOLA comportementale : balayage d'IDs, taux 403/404 anormal.

Actions graduées

Politique type

# Pseudo politique WAAP — Authentification & autorisation
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Authentification & autorisation
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Inventorier mécanismes auth par application.
2. Configurer validation token à l'entrée.
3. Protéger endpoints admin avec règles fortes.
4. Limiter flows login/reset/MFA.
5. Mettre en place tests BOLA/BFLA automatisés.
6. Analyser les 401/403 comme signaux de reconnaissance.

Rôles recommandés

Communication de crise

Incident WAAP — Authentification & autorisation
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. JWT vérifiés.
2. BOLA testé côté code.
3. mTLS partenaires si critique.
4. Routes admin isolées.
5. Rate limits auth par compte et IP.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Credential stuffing distribué faible bruit.
• Scraping de prix ou contenu avec rotation IP.
• Création massive de comptes et abus promotionnels.
• Scalping de tickets/stock limité.
• Blocage accidentel des moteurs de recherche ou monitoring.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Rythme de navigation trop régulier, absence d'interactions normales, user-agent incohérent.
• Échecs login faibles mais distribués sur grand volume de comptes.
• Sessions très courtes avec accès direct à endpoints coûteux.
• Empreinte TLS/navigateur incohérente avec user-agent déclaré.
• Réutilisation de patterns de headers ou ordre de headers.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Score bot et réponse graduée : allow, monitor, rate-limit, challenge, block.
• Protection login avec compte+IP+device+ASN, pas seulement IP.
• Challenges uniquement quand nécessaires pour réduire friction.
• Allowlist bons bots vérifiée par DNS inverse ou mécanisme fiable.
• Règles métier anti-abus : panier, réservation, coupon, vote.

Actions graduées

Politique type

# Pseudo politique WAAP — Bot management
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Bot management
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Définir bons bots et partenaires.
2. Activer scoring en observation.
3. Protéger les flows login/signup/reset.
4. Créer seuils par compte, device, IP et ASN.
5. Mesurer impact UX des challenges.
6. Créer dashboard fraude et bot par business flow.

Rôles recommandés

Communication de crise

Incident WAAP — Bot management
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Bons bots vérifiés.
2. Credential stuffing monitoré.
3. Challenge progressif.
4. Pas de blocage SEO accidentel.
5. Flux métier sensibles protégés.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• HTTP GET flood sur page dynamique non cachée.
• POST flood sur login ou search.
• GraphQL requêtes coûteuses.
• Slowloris/slow POST si timeouts mal réglés.
• Amplification applicative : requête petite, réponse ou calcul énorme.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Hausse p95/p99 latence avant hausse globale du trafic.
• CPU/DB pool saturés sur quelques endpoints.
• Taux de cache miss anormal.
• Connexions longues, faibles débits, headers incomplets.
• Distribution ASN/pays inhabituelle ou rotation IP massive.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Rate limiting par endpoint et coût.
• Cache agressif sur contenus publics et mode under attack.
• Challenge ou JavaScript/captcha seulement sur flux suspects.
• Timeouts serveur et limites body/header.
• Délestage : désactiver fonctions coûteuses non essentielles.
• Priorisation utilisateurs authentifiés ou clients premium.

Actions graduées

Politique type

# Pseudo politique WAAP — DDoS applicatif L7
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — DDoS applicatif L7
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Identifier top endpoints coûteux avant incident.
2. Définir seuils normaux et seuils de crise.
3. Préparer règles emergency par application.
4. Tester timeouts et limites body/header.
5. Préparer mode dégradé : cache, désactivation export, page statique.
6. Créer procédure d'escalade réseau/app/SOC.

Rôles recommandés

Communication de crise

Incident WAAP — DDoS applicatif L7
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Endpoints coûteux inventoriés.
2. Mode under attack testé.
3. Timeouts serveurs définis.
4. Cache stratégie prête.
5. Runbook DDoS L7 disponible.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Bloquer une entreprise entière derrière un NAT.
• Laisser un token partenaire saturer une API.
• Limiter trop tard, après consommation DB ou backend.
• Ne pas fournir headers de quota clairs aux clients APIs.
• Oublier les quotas par business flow : coupon, OTP, reset password.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Rythme requête par token/client/tenant.
• Coût moyen par endpoint et dépassement budget CPU/DB.
• Burst soudain sur endpoint historiquement stable.
• Taux de 429, retries clients, backoff respecté ou non.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Token bucket / leaky bucket / fixed window selon besoin.
• Quotas par endpoint et coût.
• Rate limit par identité forte quand disponible.
• Headers RateLimit-* ou équivalents pour APIs.
• Réponses 429 cohérentes et Retry-After.
• Bypass contrôlé pour monitoring interne.

Actions graduées

Politique type

# Pseudo politique WAAP — Rate limiting & quotas
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Rate limiting & quotas
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Classer endpoints par coût et criticité.
2. Définir identifiants de limitation fiables.
3. Mettre monitor-only puis soft limit.
4. Documenter réponses 429.
5. Surveiller les retries agressifs.
6. Ajuster quotas par contrat client.

Rôles recommandés

Communication de crise

Incident WAAP — Rate limiting & quotas
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Limites par endpoint.
2. Limites par identité.
3. 429 documenté.
4. Retry-After présent.
5. Dashboards saturation et quotas.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Schéma obsolète provoquant faux positifs.
• Mode strict activé sur API encore instable.
• Endpoints partenaires non documentés.
• Formats flexibles difficiles à modéliser : multipart, webhooks tiers.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Champ inconnu ou type inattendu.
• Content-Type différent du contrat.
• Méthode HTTP non prévue.
• Body trop profond ou trop volumineux.
• Écart persistant entre découverte automatique et schéma versionné.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Validation OpenAPI par path/method/status.
• JSON Schema pour payloads critiques.
• Enumérations et formats : UUID, email, date, montant.
• GraphQL persisted queries et limitation complexité.
• Mode compatible : monitor, warn, block par endpoint.

Actions graduées

Politique type

# Pseudo politique WAAP — Validation positive & schémas
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Validation positive & schémas
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Collecter OpenAPI/GraphQL schemas.
2. Comparer schéma et trafic réel.
3. Corriger documentation ou code.
4. Activer blocage uniquement sur endpoints stables.
5. Créer workflow de mise à jour schéma en CI/CD.
6. Surveiller drift après chaque release.

Rôles recommandés

Communication de crise

Incident WAAP — Validation positive & schémas
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Schémas versionnés.
2. CI vérifie le contrat.
3. Mode strict par endpoint critique.
4. Drift alerting actif.
5. Mass assignment réduit.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Modèle opaque difficile à expliquer au SOC.
• Poisoning ou apprentissage sur trafic déjà attaqué.
• Biais sur populations légitimes rares : pays, devices, partenaires.
• Surconfiance dans un score faible sans contrôle déterministe.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Vitesse et séquence de navigation.
• Distribution endpoints par session.
• Écart avec baseline horaire/jour/semaine.
• Combinaison réputation IP, fingerprint, erreurs, payload, identité.
• Changement soudain de schéma ou cardinalité.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Score utilisé pour challenge ou rate-limit avant blocage dur.
• Auto-tuning avec validation humaine.
• Explications : facteurs de score, règles déclenchées, comparaison baseline.
• Fenêtres d'apprentissage contrôlées.
• Exclusion des périodes d'attaque de l'entraînement.

Actions graduées

Politique type

# Pseudo politique WAAP — Machine learning & scoring
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Machine learning & scoring
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Définir features acceptables et privacy-friendly.
2. Activer scoring en observation.
3. Comparer score avec incidents historiques.
4. Définir seuils monitor/challenge/rate-limit/block.
5. Auditer dérive modèle et biais.
6. Exiger explications lisibles dans l'alerte.

Rôles recommandés

Communication de crise

Incident WAAP — Machine learning & scoring
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Scoring explicable.
2. Pas de blocage dur purement opaque sur flux critique.
3. Données sensibles minimisées.
4. Fenêtres d'entraînement connues.
5. Dérive surveillée.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Exception globale sur une règle critique au lieu d'une exception limitée à un paramètre et endpoint.
• Mode detection-only oublié pendant des mois.
• Bloquer sans regarder le score cumulé et le contexte.
• Règles custom non testées ou contradictoires.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Rule ID, phase, variable inspectée, transformation, score, action, endpoint, payload masqué.
• Fréquence par règle et par application.
• Règles les plus bruyantes et taux de faux positifs.
• Exceptions actives, propriétaires et dates d'expiration.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Niveaux de paranoia/tuning progressif.
• Score d'anomalie par famille : SQLi, XSS, protocol, RFI/LFI.
• Exceptions ciblées : endpoint + paramètre + méthode + règle.
• Tests de non-régression WAAP.
• Revue régulière des règles custom.

Actions graduées

Politique type

# Pseudo politique WAAP — Rules engine, CRS & politiques
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Rules engine, CRS & politiques
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Importer règles managées/CRS.
2. Démarrer en monitor.
3. Identifier top faux positifs.
4. Créer exceptions minimales.
5. Passer en blocage par familles haute confiance.
6. Versionner et tester les règles custom.
7. Revoir exceptions expirées.

Rôles recommandés

Communication de crise

Incident WAAP — Rules engine, CRS & politiques
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Règles versionnées.
2. Exceptions minimales.
3. Scores compris.
4. Mode monitor/block documenté.
5. Tests de règles automatisés.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Désactiver toute une famille de règles pour un seul champ.
• Ne pas expirer les exceptions.
• Traiter un faux positif sans comprendre pourquoi le payload est légitime.
• Passer en blocage sans échantillonnage suffisant.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Règles bruyantes par endpoint.
• Taux de conversion ou erreurs business après activation.
• Tickets support liés à blocage.
• Différence entre blocked requests et incidents confirmés.
• Payloads légitimes répétés par utilisateurs connus.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Exception granulaire.
• Mode canary par pourcentage de trafic ou route.
• Fenêtre d'observation avant blocage.
• Tests de replay de trafic.
• Gouvernance : owner, raison, date expiration.

Actions graduées

Politique type

# Pseudo politique WAAP — Faux positifs & tuning
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Faux positifs & tuning
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Collecter événements bloqués.
2. Qualifier vrai/faux positif avec owner app.
3. Décider : correction app, schéma, exception, règle custom.
4. Créer exception minimale.
5. Tester replay bon/mauvais trafic.
6. Définir expiration et revue.
7. Documenter dans changelog WAAP.

Rôles recommandés

Communication de crise

Incident WAAP — Faux positifs & tuning
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Aucune exception globale non justifiée.
2. Chaque exception a owner et expiration.
3. Replay tests disponibles.
4. Top règles bruyantes suivies.
5. Business impact mesuré.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Logs sans request-id ou app owner.
• Payloads sensibles stockés en clair.
• Alerting trop large générant fatigue.
• Événements WAAP non corrélés avec logs backend, CDN, IAM et DB.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Action WAAP : allow, log, challenge, rate-limit, block.
• Règles déclenchées, score, endpoint, méthode, status final.
• Identité : user, token hash, client id, tenant, session si disponible.
• Contexte réseau : IP, ASN, pays, réputation, POP, fingerprint.
• Résultat backend : status, latence, taille réponse, erreur.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Schéma de log commun JSON.
• Redaction des secrets, tokens, cookies, données personnelles.
• Dashboards par risque et par application.
• Alertes multi-signal : score élevé + endpoint critique + erreurs backend.
• Playbooks SOAR pour blocage temporaire, ticket et notification owner.

Actions graduées

Politique type

# Pseudo politique WAAP — Observabilité & SOC
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Observabilité & SOC
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Définir modèle d'événement WAAP.
2. Mettre request-id bout en bout.
3. Configurer exports SIEM.
4. Créer dashboards par persona : SOC, AppSec, Ops, métier.
5. Mettre alertes à seuils adaptatifs.
6. Tester une enquête complète sur attaque simulée.

Rôles recommandés

Communication de crise

Incident WAAP — Observabilité & SOC
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Request-id corrélé.
2. Redaction secrets.
3. Dashboards SOC/AppSec.
4. Alertes multi-signal.
5. Runbooks liés aux alertes.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Schéma API non mis à jour avant activation stricte.
• Règle custom modifiée manuellement hors Git.
• Exception de crise jamais réintégrée proprement.
• Staging ne reflète pas le trafic réel, donc blocage surprise en prod.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Diff entre OpenAPI Git et endpoints observés.
• Politique modifiée hors pipeline.
• Exceptions créées sans ticket.
• Augmentation des 403/429 après release.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Policy as code avec revue PR.
• Tests de règles WAAP sur jeux de requêtes légitimes/malveillantes contrôlées.
• Canary policy et rollback automatique.
• Sync OpenAPI depuis CI.
• Drift detection production vs repository.

Actions graduées

Politique type

# Pseudo politique WAAP — DevSecOps & CI/CD
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — DevSecOps & CI/CD
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Mettre politiques WAAP sous Git.
2. Créer pipeline lint/test des règles.
3. Ajouter export OpenAPI automatique.
4. Déployer en staging monitor-only.
5. Canary sur 5% trafic ou application pilote.
6. Surveiller erreurs et rollback si seuil dépassé.

Rôles recommandés

Communication de crise

Incident WAAP — DevSecOps & CI/CD
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Règles sous Git.
2. OpenAPI générée en CI.
3. Tests WAAP automatisés.
4. Canary disponible.
5. Drift alerting actif.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Bloquer un pays/ASN sans mesurer l'impact métier.
• Changer plusieurs règles à la fois sans journal.
• Oublier de retirer les règles temporaires.
• Ne pas prévenir les owners applicatifs lors d'un mode crise.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Spike d'alertes par règle ou endpoint.
• Latence/erreurs backend corrélées.
• Campagne multi-IP avec mêmes patterns.
• Écart soudain des revenus/conversions/logins.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• War room avec rôles : incident commander, WAAP operator, app owner, SOC analyst.
• Règles emergency pré-approuvées.
• Changements horodatés et réversibles.
• Posture progressive : monitor → rate-limit/challenge → block ciblé.
• Communication interne et post-mortem.

Actions graduées

Politique type

# Pseudo politique WAAP — Incident response WAAP
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Incident response WAAP
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Déclarer incident et périmètre.
2. Identifier endpoints touchés et impact.
3. Appliquer mitigation minimale efficace.
4. Surveiller KPIs techniques et métier.
5. Documenter chaque changement.
6. Retirer règles temporaires après stabilisation.
7. Créer post-mortem et actions préventives.

Rôles recommandés

Communication de crise

Incident WAAP — Incident response WAAP
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Runbooks prêts.
2. Rôles définis.
3. Règles emergency testées.
4. Journal de changements.
5. Post-mortem obligatoire.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Stocker Authorization, cookies ou payloads sensibles.
• Exporter des logs vers région non autorisée.
• Conserver trop longtemps des données détaillées.
• Donner accès complet WAAP à trop d'opérateurs.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Présence de champs sensibles dans logs.
• Accès administrateur aux politiques.
• Changements de règles sans ticket.
• Flux transfrontaliers de journaux ou données d'inspection.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Redaction avant stockage et export.
• Hash des identifiants quand possible.
• RBAC strict et MFA pour console WAAP.
• Rétention différenciée : événements agrégés vs échantillons détaillés.
• Audit trail immuable des changements.

Actions graduées

Politique type

# Pseudo politique WAAP — Conformité & données sensibles
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Conformité & données sensibles
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Classifier données visibles par WAAP.
2. Définir règles de redaction.
3. Valider région et rétention des logs.
4. Configurer RBAC et audit trail.
5. Tester export SIEM avec données masquées.
6. Revoir accès console chaque trimestre.

Rôles recommandés

Communication de crise

Incident WAAP — Conformité & données sensibles
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Secrets masqués.
2. Rétention définie.
3. RBAC activé.
4. Audit trail complet.
5. Données sensibles minimisées.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Choisir uniquement par prix sans évaluer faux positifs, support, API security et bot management.
• Oublier les environnements non publics : partenaires, staging, back-office.
• Négliger la compétence opérateur en open source.
• Créer plusieurs WAAP non synchronisés.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Contraintes de données/régions.
• Volume de trafic et pics.
• Nombre d'applications et APIs.
• Équipe disponible pour tuning.
• Besoin d'automatisation via API/Terraform.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• SaaS edge pour Internet exposé et DDoS.
• Cloud provider WAAP pour intégration native LB/API gateway.
• On-prem reverse proxy pour données sensibles internes.
• Open source ModSecurity/Coraza pour contrôle et lab.
• Managed WAAP pour organisation sans équipe dédiée.

Actions graduées

Politique type

# Pseudo politique WAAP — Modèles de déploiement
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Modèles de déploiement
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Lister contraintes non négociables.
2. Comparer couverture WAF/API/bot/DDoS.
3. Tester faux positifs sur trafic réel anonymisé.
4. Évaluer automation, export SIEM, RBAC.
5. Réaliser POC sur une application critique et une API.

Rôles recommandés

Communication de crise

Incident WAAP — Modèles de déploiement
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Critères de choix écrits.
2. POC avec trafic réel.
3. Support et SLA évalués.
4. Automation disponible.
5. Plan multi-environnement défini.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Inspecter intégralement des uploads massifs sans limite.
• Buffering incompatible avec streaming ou WebSockets.
• Règles coûteuses sur endpoints haut volume.
• Fail-closed non assumé ou fail-open non documenté.
• Cache mal configuré exposant données personnalisées.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Latence ajoutée p50/p95/p99.
• Taux de cache hit/miss.
• Temps de décision WAAP.
• Taille body moyenne/max.
• Erreurs 499/502/504/429/403 après changement politique.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Limites body/header par endpoint.
• Inspection partielle ou bypass contrôlé pour flux volumineux sûrs.
• Cache public strictement séparé du contenu personnalisé.
• Health checks origine et circuit breakers.
• Capacity planning et tests charge avec WAAP activé.

Actions graduées

Politique type

# Pseudo politique WAAP — Performance & disponibilité
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Performance & disponibilité
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Mesurer baseline sans/avec WAAP.
2. Classer endpoints volumineux, streaming, WebSocket.
3. Définir limites body/header/timeouts.
4. Tester charge et attaques simulées.
5. Optimiser règles bruyantes et coûteuses.
6. Préparer plan failover.

Rôles recommandés

Communication de crise

Incident WAAP — Performance & disponibilité
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Latence mesurée.
2. Limites par endpoint.
3. Cache sécurisé.
4. Failover testé.
5. Charge testée avec WAAP.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.

Niveaux de maturité

Menaces et dérives principales

• Tester uniquement avec payloads génériques hors contexte.
• Oublier les APIs, webhooks, GraphQL et mobile flows.
• Ne pas vérifier les alertes SIEM.
• Faire des tests de charge sans accord ni fenêtre.

Matrice menace → impact → réponse

Priorisation

1. Commencer par les endpoints exposés Internet et non authentifiés.
2. Ajouter les flux authentifiés critiques : login, paiement, compte, admin, exports.
3. Traiter les APIs partenaires et webhooks avec contrôles d’identité forts.
4. Ne passer en blocage large qu’après observation, tuning et validation métier.

Signaux à collecter

• Taux de passage des tests légitimes.
• Taux de blocage des cas malveillants contrôlés.
• Qualité des alertes générées.
• Impact p95/p99 sous charge.
• Diff comportement staging/prod.

Champs de log recommandés

Corrélation utile

WAAP event
                    + CDN / edge telemetry
                    + reverse proxy access log
                    + application request_id
                    + IAM/auth event
                    + DB/API downstream latency
                    = incident exploitable par SOC + AppSec + Ops

Contrôles WAAP applicables

• Jeux de requêtes légitimes anonymisées.
• Tests négatifs sûrs et autorisés.
• DAST sur staging avec WAAP monitor/block.
• Replay avant passage en blocage.
• Validation SIEM : alerte, enrichissement, runbook.

Actions graduées

Politique type

# Pseudo politique WAAP — Tests, validation & pentest
                    scope:
                    application: app_name
                    endpoints: critical_or_public
                    mode: monitor_then_enforce
                    controls:
                    normalize_http: true
                    managed_rules: enabled
                    api_schema_validation: progressive
                    bot_score: adaptive
                    rate_limit: per_identity_and_endpoint
                    logging: masked_json
                    governance:
                    owner: application_team
                    exceptions: minimal_with_expiry
                    review_cycle: 14_days

Exemple concret

Exemples de décisions sûres

Cas de test défensifs

# Tests contrôlés en staging — Tests, validation & pentest
                    1. Requête légitime attendue -> doit passer.
                    2. Requête avec méthode interdite -> doit être bloquée ou journalisée selon mode.
                    3. Requête avec champ non documenté -> doit générer alerte schema drift.
                    4. Requête trop fréquente sur endpoint coûteux -> doit produire 429 contrôlé.
                    5. Événement WAAP -> doit apparaître dans SIEM avec request_id.

Architecture d'intégration

• Placer le point d'inspection au plus proche de l'entrée : CDN/edge, reverse proxy, ingress Kubernetes, API gateway ou proxy dédié.
• Conserver une chaîne de confiance explicite : TLS, headers d'origine, adresse client réelle, identité applicative, corrélation request-id.
• Séparer les décisions : observer, scorer, challenger, limiter, bloquer, journaliser, escalader.
• Prévoir un mode monitor-only par périmètre avant blocage, puis une montée graduelle par applications critiques.
• Connecter les événements à SIEM/SOAR, APM, logs applicatifs, inventaire API et workflow de ticketing.

Points de décision

Client / Bot / Partner
                    |
                    v
                    DNS / CDN / Edge WAAP
                    |
                    v
                    Reverse proxy / Load balancer
                    |
                    v
                    Ingress / API Gateway
                    |
                    v
                    Application / Service / DB
                    |
                    +--> Logs + Metrics + Traces + SIEM

Runbook opérationnel

1. Créer corpus de trafic légitime.
2. Créer corpus de tests négatifs sûrs.
3. Exécuter en CI/staging.
4. Comparer décisions attendues/réelles.
5. Corriger règles ou schéma.
6. Valider alertes SIEM.
7. Archiver résultats pour audit.

Rôles recommandés

Communication de crise

Incident WAAP — Tests, validation & pentest
                    Impact: application / endpoint / région
                    Action: monitor | challenge | rate-limit | block
                    Risque métier: faible | moyen | élevé
                    Rollback: procédure + owner
                    Next review: heure/date
                    Evidence: dashboard + request_id + ticket

Checklist spécifique

1. Corpus légitime.
2. Tests négatifs autorisés.
3. CI/staging intégré.
4. Alertes vérifiées.
5. Résultats historisés.

KPIs à suivre

• Taux de blocage par famille de menace, par application, par endpoint et par pays/ASN.
• Ratio faux positifs / vrais positifs, temps moyen de tuning et nombre d'exceptions temporaires ouvertes.
• p95/p99 de latence ajoutée par la couche WAAP et taux d'erreurs 4xx/5xx induites.
• Couverture API : endpoints connus, endpoints découverts automatiquement, endpoints orphelins ou non documentés.
• MTTD/MTTR sur attaques applicatives : détection, qualification, mitigation, retour à l'état nominal.