# VULNÉRABLE : IDOR classique - aucune vérification que la facture appartient à l'utilisateur connecté
@app.get("/invoices/{invoice_id}")
async def get_invoice_vulnerable(invoice_id: int, current_user=Depends(get_current_user)):
    return db.query(Invoice).filter(Invoice.id == invoice_id).first()
# Un utilisateur connecté peut incrémenter invoice_id (1, 2, 3...) et lire les factures des autres

# CORRECT : vérification systématique de la propriété de la ressource (ownership check)
from fastapi import HTTPException

@app.get("/invoices/{invoice_id}")
async def get_invoice_safe(invoice_id: int, current_user=Depends(get_current_user)):
    invoice = db.query(Invoice).filter(
        Invoice.id == invoice_id,
        Invoice.user_id == current_user.id,   # clause obligatoire, pas une vérification a posteriori
    ).first()
    if invoice is None:
        raise HTTPException(status_code=404, detail="Facture introuvable")  # 404, pas 403 (évite l'énumération)
    return invoice

# Alternative robuste : identifiants non séquentiels (UUID v4) pour compliquer l'énumération
# NOTE : ce n'est PAS une protection suffisante à elle seule, seulement une défense en profondeur
import uuid
from sqlalchemy import Column
from sqlalchemy.dialects.postgresql import UUID

class Invoice(Base):
    __tablename__ = "invoices"
    id = Column(UUID(as_uuid=True), primary_key=True, default=uuid.uuid4)
    user_id = Column(UUID(as_uuid=True), nullable=False)
    # ... le contrôle d'accès explicite (filter user_id == current_user.id) reste OBLIGATOIRE

# Défaillances classiques de "broken authentication"
1. Identifiants de session prévisibles ou trop courts (facilement devinables/brute-forçables)
2. Absence d'expiration de session -> un token volé reste valide indéfiniment
3. Session non invalidée après changement de mot de passe (l'ancien token reste actif)
4. Session fixation : le serveur accepte un ID de session fourni par l'attaquant avant authentification
5. Timeout d'inactivité absent sur des applications sensibles (banque, admin)

# Bonne gestion de session : régénérer l'ID de session à chaque élévation de privilège (login)
# et invalider toutes les sessions existantes lors d'un changement de mot de passe
from datetime import datetime, timedelta, timezone

def create_session(user_id: int, session_store) -> str:
    session_id = secrets.token_urlsafe(32)   # nouvel ID à CHAQUE login, jamais réutilisé (anti session fixation)
    session_store[session_id] = {
        "user_id": user_id,
        "created_at": datetime.now(timezone.utc),
        "expires_at": datetime.now(timezone.utc) + timedelta(hours=8),
    }
    return session_id

def invalidate_all_sessions_for_user(user_id: int, session_store):
    # Appelé lors d'un changement de mot de passe, d'un logout global, ou d'une compromission suspectée
    to_remove = [sid for sid, data in session_store.items() if data["user_id"] == user_id]
    for sid in to_remove:
        del session_store[sid]

# JWT : bien gérer l'expiration ET la révocation (un JWT est stateless, donc pas "révocable" nativement)
# -> utiliser une durée de vie courte pour l'access token + refresh token stocké côté serveur (révocable)
POST /auth/refresh
Authorization: Bearer <refresh_token>

# Access token : 15 minutes de durée de vie typique
# Refresh token : stocké en base, révocable, rotation à chaque utilisation (refresh token rotation)

# Checklist IDOR / broken auth pour une revue de code
- Chaque endpoint qui prend un ID en paramètre filtre-t-il aussi sur l'utilisateur/tenant courant ?
- Les erreurs "non trouvé" vs "non autorisé" sont-elles uniformisées (404 pour éviter l'énumération) ?
- Les sessions expirent-elles et sont-elles invalidées lors d'un changement de mot de passe ?
- Les tokens JWT ont-ils une durée de vie courte, avec refresh token révocable côté serveur ?