LES ACTUALITÉS DU JOUR DANS LES MÉTIERS DU WEB - MARMITS.COM - REIMS

Le marché devient de plus en plus polarisé. D’un côté, une partie des startups européennes peine à refinancer sa croissance depuis plusieurs années. De l’autre, quelques sociétés parviennent à concentrer capital, attention des investisseurs et vitesse d’exécution à un rythme rarement observé dans la tech européenne. Lucis fait désormais partie de cette seconde catégorie. Fondée …

L’article En moins d’un an, LUCIS passe de Y Combinator à une Série A de 20 millions de dollars est apparu en premier sur FW.MEDIA.

IDOR signifie Insecure Direct Object Reference, soit « Référence directe non sécurisée à un objet ». Si le nom est un peu pompeux, la faille est très basique, et a défrayé l'actualité récemment.

Il existe des failles de sécurité spectaculaires, celles qui nécessitent des semaines de reverse engineering au fin fond de la Sibérie et une capuche noire. Et puis il y a les failles IDOR : n'importe qui avec un navigateur et quelques minutes devant lui peut les exploiter. Ce qui les rend bien plus dangereuses.

Le principe : votre application ou site web expose un identifiant dans une URL, un champ de formulaire, un paramètre d'API, qui pointe directement vers une ressource en base de données. Par exemple un numéro de commande, un identifiant de facture.

https://monapp.com/facture?id=1042

Vous consultez votre facture n°1042. Par curiosité (ou malveillance), vous remplacez 1042 par 1041 dans la barre d'adresse. Et hop — vous voilà en train de lire la facture de votre voisin. Félicitations, vous venez de découvrir une faille IDOR.

Si côté serveur vous ne vérifiez pas que l'utilisateur connecté a bien le droit d'accéder à cette ressource, n'importe qui peut modifier l'identifiant et accéder aux données d'autrui.

Ce n'est pas un bug rare : l'OWASP (Open Worldwide Application Security Project - l'organisation de référence en sécurité web) classe ce type de vulnérabilité depuis des années dans le top 10, sous la catégorie Broken Access Control. Autrement dit, c'est un problème de sécurité très répandu sur le web.

Pourquoi c'est si fréquent ?

Parce que c'est simple à faire et simple à oublier 🧠

Quand on développe une fonctionnalité et qu'on débute sans beaucoup d'expérience en sécurité, on ne se demande pas toujours "Et si quelqu'un changeait cet id à la main ?"

Les identifiants numériques auto-incrémentés (1, 2, 3...) aggravent le problème : ils sont faciles et pratiques à mettre en place dans toute base de données, par exemple avec AUTO_INCREMENT dans MySQL / MariaDB, mais ils sont devinables, prévisibles, et donnent une fausse impression d'opacité parce qu'ils sont "juste un chiffre". En réalité, on comprend tout de suite qu'on peut les modifier dans une URL.

Or... l'IDOR ne se cache pas uniquement dans les URLs. On la trouve partout où un identifiant de ressource transite par le client :

• Paramètre GET : ?user_id=42
• Corps d'une requête POST : { "invoice_id": 1042 }
• APIs REST : GET /api/commandes/4242 ou équivalent en graphQL
• En-têtes HTTP personnalisés
• Cookies

Bref, par la nature même de la relation URL 🔀 données en base, la situation est courante.

(Exemple fictif, à ne pas reproduire chez vous)

Exemples concrets

En PHP

<?php

// ❌ Code à ne pas reproduire

// L'utilisateur est connecté, on récupère son profil
session_start();

$invoiceId = $_GET['id']; // Récupéré directement depuis l'URL

$stmt = $pdo->prepare("SELECT * FROM invoices WHERE id = ?");
$stmt->execute([$invoiceId]);
$invoice = $stmt->fetch();

if ($invoice) {
    echo "Montant : " . $invoice['amount'] . " €";
} else {
    echo "Facture introuvable.";
}

Ici, on filtre les injections SQL (OK c'est déjà ça), mais on ne vérifie pas si la facture appartient à l'utilisateur connecté. N'importe quel utilisateur authentifié peut accéder à n'importe quelle facture en changeant le paramètre id, et récupérer des données personnelles. En écrivant un petit script automatique, on peut écumer comme cela toutes les valeurs possibles et récupérer toutes les factures avec les coordonnées de tous les clients.

<?php
session_start();

// On s'assure que l'utilisateur est bien connecté
if (!isset($_SESSION['user_id'])) {
    http_response_code(401);
    exit('Non autorisé');
}

$invoiceId = (int) $_GET['id'];
$currentUserId = $_SESSION['user_id'];

// La requête filtre à la fois sur l'id de la facture ET sur l'utilisateur connecté
$stmt = $pdo->prepare("SELECT * FROM invoices WHERE id = ? AND user_id = ?");
$stmt->execute([$invoiceId, $currentUserId]);
$invoice = $stmt->fetch();

if ($invoice) {
    echo "Montant : " . $invoice['amount'] . " €";
} else {
    // On ne distingue pas "n'existe pas" de "pas autorisé" — c'est voulu
    http_response_code(404);
    echo "Facture introuvable.";
}

✅ C'est mieux... Cette fois la requête SQL inclut AND user_id = ? avec l'identifiant de la session serveur — que l'utilisateur ne peut pas falsifier. Même en changeant l'id dans l'URL, il ne verra jamais les données des autres. C'est un exemple très simple par rapport à ce qu'on peut écrire dans d'autres situations pour des applications complexes, mais cela reste efficace.

Retourner une erreur 404 plutôt qu'une erreur 403 quand la ressource existe mais n'appartient pas à l'utilisateur est une bonne pratique : on évite de confirmer à l'attaquant que la ressource existe bel et bien.

En JavaScript (Node.js / Express)

Côté back-end JavaScript, le problème est exactement le même.

// ❌ Code à ne pas reproduire

// Express.js
app.get('/api/documents/:id', authenticateBidule, async (req, res) => {
  const documentId = req.params.id;

  // On cherche le document par son id
  const document = await Document.findById(documentId);

  if (!document) {
    return res.status(404).json({ error: 'Document introuvable' });
  }

  res.json(document);
});

L'utilisateur est authentifié (via authenticateBidule) mais le document renvoyé peut appartenir à n'importe qui d'autre.

La version avec contrôle d'accès

app.get('/api/documents/:id', authenticateBidule, async (req, res) => {
  const documentId = req.params.id;
  const currentUserId = req.user.id; // Injecté par le middleware d'auth, non falsifiable

  const document = await Document.findOne({
    _id: documentId,
    userId: currentUserId // On filtre aussi sur le propriétaire
  });

  if (!document) {
    // 404 et non 403, pour ne pas confirmer l'existence de la ressource
    return res.status(404).json({ error: 'Document introuvable' });
  }

  res.json(document);
});

✅ C'est mieux. Il y a cette fois la vérification nécessaire.

Dans les projets plus structurés, il vaut mieux isoler la logique de contrôle d'accès dans un fichier commun dédié plutôt que de la répartir de façon répétitive dans chaque route, d'autant plus qu'elle sera facile à oublier.

Une piste complémentaire : les identifiants non-devinables

Filtrer sur le propriétaire est la protection principale et non négociable. Mais utiliser des identifiants non séquentiels ajoute une couche de protection supplémentaire. Au lieu d'un id auto-incrémenté (1, 2, 3...), on peut utiliser un UUID :

/facture/3b12f1df-5232-4804-8b9a-c5d3e5f8a2b1

Un UUID v4 est aléatoire et pratiquement impossible à deviner. Ça ne remplace pas le contrôle d'accès — un attaquant qui connaît un UUID valide peut toujours tenter sa chance — mais cela rend l'énumération quasiment impossible à exploiter.

En PHP :

// Génération d'un UUID v4 avec ramsey/uuid
use Ramsey\Uuid\Uuid;

$uuid = Uuid::uuid4()->toString();

En JavaScript :

import { v4 as uuidv4 } from 'uuid';

const id = uuidv4();

Ce qu'il faut retenir

Les failles IDOR sont répandues, simples à exploiter et souvent invisibles lors d'une revue de code inattentive. La bonne nouvelle, c'est qu'elles sont aussi simples à corriger... encore faut-il y penser : ne jamais faire confiance à un identifiant venant du client sans vérifier côté serveur que l'utilisateur connecté a le droit d'y accéder.

La checklist finale :

• Toujours vérifier la propriété de la ressource dans vos requêtes, côté serveur, en croisant avec l'identifiant de session.
• Ne jamais faire confiance à un user_id ou tout autre id envoyé par le client — il doit venir de la session, pas de la requête.
• Favoriser les UUIDs plutôt que les identifiants séquentiels pour compliquer l'énumération.
• Retourner une erreur 404 quand une ressource existe mais n'appartient pas à l'utilisateur, pour ne pas confirmer son existence.
• Centraliser les vérifications d'accès dans des fonctions mutualisées ou des middlewares pour éviter les oublis.
• Tester soi-même : tout simplement, se connecter avec deux comptes différents et tenter d'accéder aux ressources de l'un depuis l'autre.

Publié par Alsacreations.com

Après l’intelligence artificielle, NVIDIA avance désormais ses pions dans le quantique. Le groupe américain annonce l’entrée de son véhicule d’investissement NVentures au capital d’Alice & Bob, l’une des startups européennes les plus observées dans la course au calcul quantique tolérant aux fautes. L’opération s’inscrit dans l’extension de la Série B de 100 millions d’euros menée …

L’article NVIDIA se fait un trou de souris pour monter à bord d’Alice & Bob est apparu en premier sur FW.MEDIA.

Les annonces américaines interviennent à quelques heures d’un moment hautement symbolique pour la stratégie technologique française. Ce vendredi, Emmanuel Macron doit réunir au Très Grand Centre de calcul du CEA à Bruyères-le-Châtel une large partie de l’appareil industriel, scientifique et politique européen autour du quantique, des semi-conducteurs et des infrastructures de calcul. Le timing donne …

L’article Avec 2 milliards de dollars, Donald Trump transforme le quantique en industrie stratégique nationale est apparu en premier sur FW.MEDIA.