Fondamentaux de la sécurité applicative¶

Comprendre le périmètre, les principes de base et la méthodologie threat modeling avant d'écrire la première ligne de code.

Sécurité vs safety¶

Ces deux termes sont souvent confondus mais désignent des preoccupations distinctes :

La sécurité applicative (AppSec) couvre l'ensemble du cycle de vie logiciel : conception, développement, tests, déploiement et opérations.

Shift-left : le coût de la détection tardive¶

Plus une vulnérabilité est découverte tard, plus elle coute cher a corriger.

graph LR
    A["Conception\n1x"] --> B["Developpement\n6x"]
    B --> C["Tests\n15x"]
    C --> D["Pre-prod\n30x"]
    D --> E["Production\n100x"]
    style A fill:#2d9e2d,color:#fff
    style B fill:#7ab648,color:#fff
    style C fill:#e6a817,color:#fff
    style D fill:#e07b39,color:#fff
    style E fill:#c0392b,color:#fff

Le multiplicateur représenté le coût relatif de correction par rapport à la phase de conception.

Threat modeling : méthode STRIDE¶

Le threat modeling consiste à identifier systematiquement les menaces avant d'écrire le code.

Les 6 catégories STRIDE¶

Processus de threat modeling¶

flowchart TD
    A[Decomposer le systeme] --> B[Identifier les actifs a proteger]
    B --> C[Lister les menaces STRIDE]
    C --> D[Evaluer le risque]
    D --> E[Definir les contre-mesures]
    E --> F[Valider et documenter]
    F --> A

Étape 1 — Decomposer : diagramme de flux de données (DFD), identifier les points d'entree, les stores de données et les composants externes.

Étape 2 — Identifier les actifs : quelles données ou fonctions ont de la valeur ? (PII, tokens, secrets métier)

Étape 3 — Lister les menaces : pour chaque composant, appliquer STRIDE et noter chaque menace plausible.

Étape 4 — Évaluer : utiliser le score DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) ou simplement Haute/Moyenne/Faible.

Étape 5 — Contre-mesures : pour chaque menace retenue, définir un contrôle technique ou organisationnel.

Analyse de la surface d'attaque¶

La surface d'attaque est l'ensemble des points par lesquels un attaquant peut interagir avec le système.

graph TD
    subgraph "Surface d'attaque"
        A[API REST publique]
        B[Interface admin]
        C[Upload de fichiers]
        D[Webhooks entrants]
        E[Dependances tierces]
        F[Variables d'environnement]
    end
    G[Attaquant externe] --> A
    G --> C
    G --> D
    H[Attaquant interne] --> B
    H --> F
    I[Attaque supply chain] --> E

Réduire la surface d'attaque :

• Désactiver les fonctionnalités non utilisées
• Restreindre les endpoints par rôle
• Limiter les ports et protocols exposes
• Supprimer les dépendances inutiles

Principes fondamentaux¶

Moindre privilege¶

Chaque composant, utilisateur ou processus ne doit avoir que les droits strictement nécessaires a sa fonction.

# VULNERABLE — acces trop large
conn = psycopg2.connect(user="postgres", ...)  # superuser

# SECURISE — compte dedie avec droits limites
conn = psycopg2.connect(user="app_readonly", ...)  # SELECT uniquement

Defense en profondeur¶

Ne pas compter sur un seul contrôle de sécurité. Multiplier les couches indépendantes.

graph LR
    A[WAF] --> B[Authentification]
    B --> C[Autorisation]
    C --> D[Validation input]
    D --> E[Chiffrement DB]
    E --> F[Logs & alertes]

Fail secure¶

En cas d'erreur, le système doit échouer de manière sécurisée (accès refuse par défaut).

# VULNERABLE — fail open
def check_permission(user, resource):
    try:
        return has_permission(user, resource)
    except Exception:
        return True  # Erreur => acces autorise !

# SECURISE — fail secure
def check_permission(user, resource):
    try:
        return has_permission(user, resource)
    except Exception:
        logger.error("Permission check failed", exc_info=True)
        return False  # Erreur => acces refuse

Zero Trust¶

Ne jamais faire confiance implicitement a un réseau, un utilisateur ou un service — même interne. Toujours authentifier, autoriser et chiffrer.

Checklist de démarrage¶

Avant de commencer un nouveau projet ou feature :

• Threat model rapide réalisé (même 30 minutes)
• Surface d'attaque identifiée et documentee
• Principes STRIDE appliques aux flux principaux
• Contrôles de sécurité définis avant le code
• Critères d'acceptance sécurité inclus dans les user stories

Chapitre suivant : OWASP Top 10 — les vulnérabilités les plus courantes avec exemples concrets.