Sécurité & Observabilité Back-End

Auth, tokens, droits, journaux, métriques, traces & alerting : comment sécuriser un back-end moderne tout en gardant une observabilité fine pour prévenir et diagnostiquer les incidents.

Auth, sessions, tokens, OAuth2/OIDC & JWT Droits, RBAC/ABAC, multi-tenant & sécurité applicative Logs, métriques, traces, alerting & SRE

Sessions “classiques” (cookies)

Cookie HTTP-only, Secure, SameSite (Lax/Strict) contenant un id de session opaque.
Session stockée en DB / cache (Redis), associée à l’utilisateur & au contexte.
Adapté aux applis web “monodomaine” (pas SPA multi-origines).

Tokens portables

Token opaque : valeur aléatoire, stockée côté serveur (sécurité + révocation facile).
Token JWT : infos signées (claims) lisibles par les services, vérifiées via clé secrète / clé publique.
Attention à la durée de vie : access token courts, refresh token plus longs et mieux protégés.

OAuth2 / OpenID Connect

Serveur d’identité dédié (Keycloak, Auth0, Cognito…) qui émet des tokens.
OIDC = couche d’identité au-dessus d’OAuth2 (id_token, profil, e-mail…).
Back-end = “ressource server” qui vérifie et interprète les tokens.

Exemple de JWT (payload)

{
  "sub": "user_123",
  "iss": "https://auth.ideo-lab.com/",
  "aud": "backend-api",
  "exp": 1733700000,
  "scope": "orders:read orders:write",
  "tenant": "t42",
  "roles": ["user", "admin"]
}

➜ En back-end : vérifier signature, exp, aud, iss, puis mapper roles/scope vers les droits internes.

Checklist auth & tokens

Forcer HTTPS, désactiver les cookies non sécurisés.
Invalidate les sessions / refresh tokens en cas de reset mot de passe ou suspicion de fuite.
Limiter les scopes : un token n’a que les droits nécessaires (principe du moindre privilège).
Tracer l’origine d’un token (client id, type de flow, device) dans les logs.

RBAC vs ABAC

RBAC : rôles (admin, manager, viewer…). Simple à comprendre, mapping direct aux profils.
ABAC : décisions basées sur attributs (user, ressource, contexte) : pays, heure, tenant, etc.
Pattern courant : RBAC global + règles ABAC pour les cas sensibles.

Multi-tenant

Every requête doit être filtrée sur tenant_id côté back-end, jamais confiée au front.
Interdire d’accéder à un tenant différent même si l’ID est fourni dans l’URL.
Ajouter systématiquement tenant_id dans les logs, métriques, traces.

OWASP & sécurité applicative

Injection (SQL, NoSQL, OS) → paramétrer, utiliser des requêtes préparées, jamais concaténer.
XSS → échapper correctement le HTML, CSP, jamais injecter du JS provenant des données.
CSRF → jetons CSRF, SameSite cookies, double‐submit cookie.
SSRF, file upload, path traversal, etc. à intégrer dans les revues de code.

Exemple pseudo-code de contrôle d’accès

def can_view_order(user, order) -> bool:
    if "super_admin" in user.roles:
        return True

    if order.tenant_id != user.tenant_id:
        return False

    if "support" in user.roles:
        return True

    # user standard : ne voit que ses commandes
    return order.customer_id == user.id

➜ Centraliser ce genre de règles dans un module dédié (policy engine), pas partout dans le code.

Les 3 piliers

Logs : événements discrets, utiles pour diagnostiquer.
Métriques : séries temporelles (RPS, erreurs, latence).
Traces : chemin complet d’une requête à travers les services.

SLI / SLO

SLI = mesure (ex : % de requêtes HTTP 2xx < 300ms sur /checkout).
SLO = objectif (ex : 99.9% sur 30 jours).
Les alertes doivent être liées aux SLO, pas à des métriques brutes isolées.

Alerting sain

Pas de “tout alerter” : limiter aux signaux réellement actionnables.
Pager pour les incidents impactant l’utilisateur ou les SLO.
Alertes silencieuses ou dashboards pour la santé de fond (capacity, tendance).

Exemple : logs structurés JSON

{
  "ts": "2025-12-08T21:30:00Z",
  "level": "INFO",
  "service": "orders-api",
  "trace_id": "abc123",
  "span_id": "s1",
  "user_id": "u42",
  "tenant_id": "t1",
  "route": "POST /checkout",
  "status": 201,
  "latency_ms": 180
}

➜ Même format pour tous les services = filtrage / corrélation ultra simple dans l’outil de logs.

Mots de passe & MFA

Stockage en hashage fort (bcrypt, argon2…) avec sel.
Protection contre brute force : rate-limit, captchas, lockout progressif.
MFA pour comptes sensibles (admins, finance, support).

Sessions côté serveur

Cookie HTTP-only + Secure, éventuellement SameSite.
Session store (Redis/DB) avec TTL & invalidation après logout.
Possibilité de “device management” (liste des appareils connectés).

Tokens (mobile / API)

Access tokens courts (5–30 min) + refresh token rotatif.
Révocation côté serveur (liste noire, version de token, jti).
Rotation de refresh token : si un token ancien est présenté, alerter.

Exemple pseudo-flow OAuth2 (code flow)

1. Front redirige l'utilisateur vers /authorize (IdP).
2. L'utilisateur s'authentifie, consent aux scopes.
3. IdP redirige le front avec un "code" éphémère.
4. Le back échange ce code contre des tokens (access + refresh).
5. Le back stocke le refresh token (chiffré) et renvoie un cookie au front
   ou un token à l'app mobile.

Architecture des droits

Tables / collections dédiées aux rôles, permissions, policies.
Décider du niveau de granularité : droit sur ressource ou sur action précise.
Distinguer droits “plateforme” vs “fonctionnels”.

Vérification centralisée

Middleware / decorator @require_permission("orders.read").
Services d’autorisation dédiés pour les cas complexes (policy engine).
Tracer les refus d’accès (tentative d’escalade de privilèges).

Exemple de mapping simple rôles → scopes

ROLE_ADMIN:
  - users.read
  - users.write
  - orders.read
  - orders.write

ROLE_SUPPORT:
  - users.read
  - orders.read

ROLE_USER:
  - orders.read_own
  - orders.write_own

Sécurité & Observabilité Back-End

1. Surface d’attaque & principes clés

2. Authentification & sessions

3. Autorisation & gestion des droits

4. Sécurité des APIs & données

5. Environnements, secrets & CI/CD

6. Logs & journalisation

7. Métriques & traces

8. Alerting, SRE & gestion d’incidents