Sécuriser une API REST et une application mobile

Une API REST expose directement les données et les fonctions d'une application à d'autres programmes : front web, application mobile, services partenaires. Sa sécurité repose sur l'authentification de chaque appel, le contrôle d'accès à chaque objet et à chaque propriété, et la limitation des ressources consommées. Ce chapitre suit l'OWASP API Security Top 10 (édition 2023), puis présente les risques propres aux applications mobiles (OWASP Mobile Top 10, édition 2024) : stockage sur le téléphone, communication, authentification biométrique.

OWASP API Security Top 10 (2023)

Les API ont leurs propres failles dominantes, d'où une liste dédiée de l'OWASP.

Authentifier chaque appel

Une API n'a pas de « page de connexion » qui protège le reste : chaque requête doit prouver son identité, et chaque route doit être protégée par défaut (refuser par défaut).

Un jeton ou une clé ne passe jamais dans l'URL (?token=…) : les URL sont enregistrées dans les journaux des serveurs et des proxys, dans l'historique du navigateur, et transmises dans l'en-tête Referer. Et tout passe en HTTPS.

BOLA et BOPLA : filtrer les objets et les propriétés

BOLA est le nom de l'IDOR dans le monde des API : on corrige en vérifiant le propriétaire à chaque accès, comme au chapitre 3.

BOPLA touche les propriétés d'un objet. En lecture, l'API renvoie plus de champs que nécessaire, en comptant sur le front pour ne pas les afficher :

// VULNÉRABLE : renvoie toute la ligne, y compris mdp_hash
router.get('/api/moi', authentifier, async (req, res) => {
  const [lignes] = await pool.execute('SELECT * FROM utilisateur WHERE id = ?', [req.utilisateur.id]);
  res.json(lignes[0]);
});

L'outil de développement du navigateur montre la réponse complète : l'empreinte du mot de passe, des champs internes. La correction sélectionne explicitement les colonnes, ou passe par un objet de réponse dédié (un DTO, Data Transfer Object) :

const [lignes] = await pool.execute('SELECT id, login, email, role FROM utilisateur WHERE id = ?', [req.utilisateur.id]);
res.json(lignes[0]);

En écriture, c'est l'affectation de masse : l'API accepte des champs que l'utilisateur ne doit pas modifier (role, actif, montant_valide). La parade est la liste blanche des champs modifiables, par exemple avec un schéma de validation (chapitre 7).

Limiter la consommation de ressources

Une API sans limites se fait épuiser : par un attaquant, par un script mal écrit, ou par la facture d'un service payant appelé à chaque requête (envoi de SMS, géocodage). Les limites à poser :

const limite = Math.min(Number.parseInt(req.query.limite, 10) || 20, 100);   // 20 par défaut, 100 au maximum
const page = Math.max(Number.parseInt(req.query.page, 10) || 1, 1);
const decalage = (page - 1) * limite;
// query : avec execute, mysql2 refuse des nombres pour LIMIT ? sur MySQL 8 ; les valeurs restent échappées
const [fiches] = await pool.query(
  'SELECT id, mois, etat, montant_valide FROM fiche_frais WHERE id_visiteur = ? ORDER BY mois DESC LIMIT ? OFFSET ?',
  [req.utilisateur.id, limite, decalage]
);

limite et decalage sont des entiers calculés par le serveur, bornés : impossible de demander un million de lignes.

Méthodes HTTP et codes de retour

Chaque méthode a un sens, et les méthodes qui modifient (POST, PUT, PATCH, DELETE) appellent les contrôles les plus stricts. Le sujet E7 SLAM 2025 demandait justement pourquoi DELETE et PUT sont dangereuses : elles modifient ou suppriment des données existantes, ce qui atteint l'intégrité et la disponibilité, parfois sans retour possible (corrigé du sujet 2025).

Une route qui n'existe que pour une méthode ne doit pas en accepter d'autres : un routeur bien configuré répond 404 ou 405 aux méthodes non déclarées.

Inventorier les versions et les routes

Une API évolue : /api/v1/, puis /api/v2/. L'ancienne version, conservée « pour les vieux clients », n'a souvent pas reçu les corrections de sécurité de la nouvelle. Une route de test, une route de débogage ou une documentation interactive (Swagger UI) oubliée en production sont autant de portes ouvertes.

Les bonnes pratiques : une documentation OpenAPI à jour, qui sert d'inventaire de toutes les routes ; une date de fin annoncée pour chaque ancienne version, puis sa suppression ; pas de route de débogage ni de documentation interactive exposée en production sans authentification ; un environnement de préproduction qui ne partage pas les données de production. Le cours JavaScript et Node.js montre la construction d'une API REST avec Express.

Consommer une API tierce sans lui faire confiance

L'API d'AppliFrais appelle un service partenaire de calcul des indemnités kilométriques. Les données qu'il renvoie sont des entrées comme les autres : elles peuvent être fausses, malveillantes si le partenaire est compromis, ou absentes s'il est en panne.

• Valider la réponse (types, plages, format) avant de l'utiliser ou de l'enregistrer.
• Encoder à l'affichage ce qui vient du tiers, comme une saisie d'utilisateur.
• Appeler le tiers en HTTPS, avec un délai maximal, et prévoir le comportement en cas de panne (échouer proprement, chapitre 12).
• Ne pas suivre aveuglément les redirections renvoyées par le tiers.

Les risques des applications mobiles

Une application mobile tourne sur un appareil que l'éditeur ne contrôle pas : le téléphone peut être perdu, volé, partagé, modifié (rooté ou jailbreaké), et le code de l'application peut être décompilé. L'OWASP Mobile Top 10 (édition 2024) liste les risques dominants :

Pour vérifier une application mobile, l'OWASP publie aussi le MASVS (exigences de sécurité) et le MASTG (guide de test), l'équivalent mobile de l'ASVS et du WSTG.

Stocker des données sur le téléphone

Aucun secret dans le code de l'application. Un fichier APK (Android) se décompile en quelques minutes avec des outils gratuits comme jadx : une clé d'API ou un mot de passe écrits dans le code sont lisibles par tous. Une application mobile est un client public : elle ne peut pas garder de secret. Les appels qui exigent une clé privée passent par ton serveur, qui détient la clé.

Les données sensibles dans le stockage sécurisé du système. Android fournit le Keystore, iOS le Trousseau (Keychain) et la Secure Enclave : des espaces où les clés cryptographiques sont générées et utilisées sans jamais pouvoir être extraites, souvent dans une puce dédiée. Un jeton de rafraîchissement ou une clé de chiffrement de la base locale y ont leur place. Les préférences ordinaires (SharedPreferences sur Android, UserDefaults sur iOS) et les fichiers en clair ne conviennent pas aux secrets.

Le minimum de données sur l'appareil, effacées à la déconnexion, et exclues des sauvegardes automatiques quand elles sont sensibles.

Les requêtes sur la base locale SQLite sont préparées, comme sur un serveur : le sujet de 2024 demandait d'écrire une insertion paramétrée dans une table de journal SQLite sur Android.

Authentification biométrique

Le sujet E6 SLAM 2024 (aujourd'hui E7) portait sur une application mobile de pompiers qui déverrouillait l'accès par biométrie, avec un journal des tentatives (corrigé du sujet 2024, dossier C). Trois idées à maîtriser.

L'application ne voit jamais l'empreinte ou le visage. Elle demande au système d'exploitation d'authentifier l'utilisateur, avec BiometricPrompt sur Android ou LocalAuthentication sur iOS. Le système compare l'empreinte au modèle enregistré dans la puce sécurisée de l'appareil et répond seulement « succès » ou « échec ».

La biométrie doit débloquer quelque chose. Un simple booléen « succès » dans le code de l'application se contourne sur un téléphone modifié. La bonne pratique lie l'authentification à une clé du Keystore créée avec l'exigence d'authentification de l'utilisateur : sans empreinte valide, la clé reste inutilisable, et le jeton qu'elle chiffre aussi. L'extrait Java simplifié suivant montre le principe :

BiometricPrompt.PromptInfo infos = new BiometricPrompt.PromptInfo.Builder()
        .setTitle("Déverrouiller AppliFrais")
        .setNegativeButtonText("Utiliser le mot de passe")       // une alternative est toujours proposée
        .setAllowedAuthenticators(BiometricManager.Authenticators.BIOMETRIC_STRONG)
        .build();

BiometricPrompt invite = new BiometricPrompt(this, executeur, new BiometricPrompt.AuthenticationCallback() {
    @Override
    public void onAuthenticationSucceeded(@NonNull BiometricPrompt.AuthenticationResult resultat) {
        Cipher dechiffreur = resultat.getCryptoObject().getCipher();  // débloqué par l'empreinte
        String jeton = dechiffrerJeton(dechiffreur);                  // jeton stocké chiffré sur l'appareil
        journal.ajouter(new EntreeLog("LoginBiometrie", "Succes", "OK"));
        ouvrirAccueil(jeton);
    }

    @Override
    public void onAuthenticationError(int code, @NonNull CharSequence message) {
        journal.ajouter(new EntreeLog("LoginBiometrie", "Echec", code + " - " + message));
    }
});

invite.authenticate(infos, new BiometricPrompt.CryptoObject(dechiffreurInitialise));

La biométrie est une donnée sensible au sens du RGPD. Les données biométriques traitées pour identifier une personne de façon unique font partie des catégories particulières de données (article 9), dont le traitement est interdit par principe, sauf exceptions encadrées. Quand le modèle reste sur l'appareil, sous le seul contrôle de l'utilisateur, et que l'application n'en reçoit qu'un résultat, le risque est bien moindre qu'avec une base centrale d'empreintes. Mais dans un contexte professionnel, l'employeur doit justifier le recours à la biométrie, proposer une alternative (code, mot de passe), informer les personnes et mener une analyse d'impact si le traitement présente un risque élevé. La CNIL a publié un règlement type sur la biométrie sur les lieux de travail.

Communications de l'application mobile

• HTTPS obligatoire. Depuis Android 9, une application qui cible une version récente du système refuse par défaut le trafic en clair ; la configuration de sécurité réseau (network_security_config.xml) ne doit pas le réautoriser. Sur iOS, App Transport Security impose HTTPS par défaut.
• Ne jamais désactiver la vérification des certificats, même « temporairement pour les tests » : ce code finit en production.
• L'épinglage de certificat (certificate pinning), qui n'accepte que le certificat ou la clé attendus du serveur, protège contre une autorité de certification compromise, mais complique le renouvellement des certificats : à réserver aux applications sensibles, avec une clé de secours.
• Le serveur reste le juge. Tous les contrôles d'accès faits dans l'application mobile doivent être refaits par l'API : une application modifiée ou un script peuvent appeler l'API directement.

router.delete('/api/lignes/:id', async (req, res) => {
  await pool.execute('DELETE FROM ligne_frais WHERE id = ?', [req.params.id]);
  res.status(204).end();
});

router.delete('/api/lignes/:id', authentifier, exigerRole('visiteur'), async (req, res) => {
  const [resultat] = await pool.execute(
    `DELETE l FROM ligne_frais l
     JOIN fiche_frais f ON f.id = l.id_fiche
     WHERE l.id = ? AND f.id_visiteur = ? AND f.etat = 'CR'`,
    [req.params.id, req.utilisateur.id]
  );
  if (resultat.affectedRows === 0) return res.status(404).json({ erreur: 'Ligne introuvable ou non modifiable' });
  journaliserSecurite('suppression_ligne', req, { ressource: `ligne:${req.params.id}` });
  res.status(204).end();
});