Sécurisation des applications et API : chaque opération sensible vérifiée avant d'être exécutée.
Être connecté ne suffit pas.
Nous mettons en place, dans votre application et ses API, les contrôles qui vérifient côté serveur qui demande quoi, sur quelle ressource et pour quelle opération, avant d'agir.
Schéma : le collaborateur A, connecté, envoie deux requêtes. La première lit le dossier A-17 de son équipe : elle passe la réception, l'identité, le droit sur la ressource et le contrôle des données, puis elle est exécutée ; le dossier est renvoyé et la lecture journalisée. La seconde lit le dossier B-42 d'une autre équipe : elle passe la réception et l'identité, puis elle est arrêtée au droit sur la ressource ; le contrôle suivant n'est pas atteint. Elle est refusée par un message neutre qui ne dit pas si le dossier existe, et la tentative est journalisée.
Le passage autorisé, en six étapes
Ce qu'une application doit protéger, au-delà de la page de connexion.
La page de connexion n'est que la porte d'entrée. Ce qui compte, c'est ce que l'application permet ensuite : chaque opération, sur chaque donnée, pour chaque profil.
Les opérations
Modifier, exporter, supprimer, valider un paiement : chaque action sensible doit être autorisée au moment où elle est demandée.
Les ressources
Un dossier, une facture, un compte : l'accès se vérifie pour chaque élément demandé, pas seulement pour la page qui l'affiche.
Les données dans les échanges
Ce que l'API accepte et ce qu'elle renvoie : rien de plus que nécessaire, rien qui ne soit vérifié.
Les serveurs et l'hébergement relèvent de la sécurisation des infrastructures web.
Qui demande, a-t-il le droit, la demande est-elle valide : trois contrôles, pas un.
Ces trois questions se posent à chaque requête, dans cet ordre. Répondre à la première ne dispense jamais des deux autres.
1 · Authentification
Qui demande ?
L'identité et la session de l'appelant, personne ou logiciel. Le détail relève de l'authentification et de la gestion des accès.
✕ Refuspar exemple : la session a expiré
2 · Autorisation
A-t-il le droit ?
Le droit sur cette ressource et pour cette opération, vérifié côté serveur à chaque requête, quel que soit ce qu'affiche l'interface.
✕ Refuspar exemple : le dossier appartient à une autre équipe
3 · Validation et règles métier
La demande est-elle valide ?
Des données cohérentes, puis les règles de votre activité : une quantité positive, une commande encore modifiable, un plafond respecté.
✕ Refuspar exemple : une valeur hors des limites prévues
HTTPS protège le trajet de la requête ; il ne dit rien de ses droits.
Même requête, données différentes : l'API vérifie avant de modifier.
Simulation fictive : une demande de modification de la commande CMD-3051 arrive à l'API. Comparez une demande valide et des situations à refuser, et suivez les contrôles du serveur jusqu'à la réponse.
Situations à comparer
Demandeur
État de la commande
Modification demandée
Décision : Exécutée
Exécutée. Commande CMD-3051 mise à jour : quantité 24.
La demande reçue
Modifier la commande CMD-3051
DemandeurCommercial titulaire
Commandeen préparation
Articlechaises de bureau
Quantité20 → 24
Le formulaire de l'application contrôle déjà la saisie. Mais l'API peut recevoir une demande d'ailleurs : elle refait toutes les vérifications.
Contrôles côté serveur, dans l'ordre
Réception de la demandePassedemande bien formée
Vérification de l'identitéPassecommercial titulaire, session valide
Droit sur l'opérationPassemodifier cette commande : permis à ce profil
Validation des donnéesPassequantité 24 : nombre entier positif
Règles métierPassecommande en préparation : modifiable
Décision et réponse
Exécutée
Commande CMD-3051 mise à jour : quantité 24.
code de réponse HTTP : 200
Journal
Modification de CMD-3051, quantité 20 → 24 · commercial titulaire · horodatée.
Chaque contrôle est passé : la modification est appliquée, et tracée.
Simulation fictive : aucune application réelle n'est interrogée. La validation des données ne remplace pas le contrôle des droits : celui-ci passe toujours en premier. Ces contrôles sont des protections parmi d'autres.
Les protections que nous mettons en place, là où l'application décide.
Selon le périmètre convenu avec vous, ces mesures s'appliquent dans le code de l'application et de ses API, en tenant compte de l'architecture existante.
Ce que l'application vérifie
- Autorisation côté serveur, par ressource et par opération
- Validation des entrées et des données reçues
- Règles métier appliquées par le serveur, validations humaines comprises
- Confirmation des opérations sensibles
Comment l'API se protège
- Points d'entrée inventoriés, aucun oublié
- Limitation des appels abusifs
- Réponses d'erreur sobres, qui ne révèlent rien d'interne
- Informations sensibles retirées des réponses
- Secrets hors du code, renouvelables
Ce qui permet de vérifier
- Journalisation utile des opérations sensibles : qui, quoi, quand
- Aucune donnée sensible ni secret en clair dans les journaux
- Tests des protections, y compris de ce qui doit être refusé
Toutes ces mesures ne sont pas comprises dans chaque intervention : le périmètre retenu, et donc les protections mises en place, est écrit au devis. La protection des données au repos relève de la protection des données ; la construction des connexions entre logiciels, des API et intégrations.
Ces mesures rejoignent les recommandations publiques de l'OWASP sur la sécurité des API, auxquelles nous nous référons comme guide de bonnes pratiques, sans revendiquer de certification ni de conformité globale.
Une application en production ou en projet : on sécurise dans les deux cas.
Il n'est pas nécessaire d'attendre un incident, ni de tout réécrire. Le point de départ change, la démarche reste la même.
Une application en production
Les protections s'ajoutent sans tout réécrire, en commençant par les opérations les plus sensibles, et sont testées pour ne pas bloquer les usages légitimes. Un audit de sécurité préalable aide à prioriser, mais il n'est pas obligatoire : l'audit identifie les risques, la sécurisation met les protections en place. Ce sont deux prestations distinctes.
Une application en projet
Les règles d'accès s'écrivent avec les fonctionnalités, et les contrôles font partie du code dès le départ, que l'application soit une plateforme métier, un CRM ou un ERP ou un autre produit conçu par nos équipes de développement.
Mettre en place, puis vérifier que chaque protection tient.
Une protection qui n'a pas été essayée n'est qu'une intention. Chaque étape se termine par une vérification.
Cadrage
Applications, API, données sensibles, profils d'utilisateurs : le périmètre est écrit avec vous.
Règles d'accès
La grille « qui peut faire quoi, sur quoi » est établie et validée avec vous.
Mise en œuvre
Les protections sont intégrées au code existant ou en cours de développement.
Tests
Chaque règle est essayée, y compris celles qui doivent refuser.
Contre-vérification
Les tests sont rejoués, et les choix documentés pour vos équipes.
Suivi
Si vous le souhaitez, les protections sont maintenues dans la durée : maintenance et suivi de sécurité.
Un test d'intrusion ou un audit indépendant peuvent compléter la vérification ; ils ne sont pas inclus d'office. Aucune vérification ne garantit l'absence totale de vulnérabilités.
Questions fréquentes sur la sécurisation des applications et API
Les questions qui reviennent avant de sécuriser une application.
Quelle différence entre un audit de sécurité et la sécurisation d'une application ?
L'audit de sécurité examine l'application et remet des constats classés par priorité, avec les corrections proposées ; il ne les réalise pas. La sécurisation consiste à mettre en place et à vérifier les protections : contrôles d'accès, validation, protection des échanges. Un audit peut précéder la sécurisation, mais une application en cours de développement peut être sécurisée sans audit préalable.
Une API protégée par HTTPS est-elle suffisamment sécurisée ?
Non. HTTPS chiffre le trajet entre l'application et le serveur : personne ne peut lire ni modifier la requête en chemin. Il ne dit rien de ce que l'utilisateur a le droit de faire. Une requête chiffrée peut très bien demander un dossier qui ne lui appartient pas : c'est au serveur de vérifier les droits et les données, à chaque appel.
Pourquoi vérifier les autorisations côté serveur ?
Parce que tout ce qui se passe côté navigateur ou application mobile peut être contourné : un bouton masqué ou un champ désactivé n'empêchent pas d'envoyer directement une requête à l'API. Seul le serveur voit chaque demande et peut décider, à partir des droits réels de l'utilisateur sur la ressource et l'opération demandées.
Peut-on sécuriser une application déjà en production ?
Oui. Les protections s'ajoutent progressivement, en commençant par les opérations les plus sensibles, et sont testées avant leur mise en service pour ne pas bloquer les usages légitimes. Si le code a été écrit par un autre prestataire, son accès et sa documentation sont nécessaires ; un audit préalable aide alors à prioriser.
Faut-il sécuriser également les API internes ?
Oui, dans la mesure de ce qu'elles exposent. Une API « interne » est souvent joignable par d'autres applications, par des partenaires ou depuis un poste compromis. Les mêmes principes s'appliquent : identifier l'appelant, vérifier ses droits, valider les données. Leur niveau se décide selon les données et les opérations concernées.
Comment vérifier que les protections fonctionnent ?
Chaque règle est testée, y compris celles qui doivent refuser : un profil qui tente une opération interdite, une ressource d'une autre équipe, des données hors limites. Ces tests sont documentés et rejoués après les évolutions. Un test d'intrusion ou un audit indépendant peuvent compléter la vérification ; ils ne sont pas inclus d'office, et aucune vérification ne garantit l'absence totale de vulnérabilités.
Sécuriser ce que votre application permet de faire.
Une intervention commence par comprendre l'application : qui l'utilise, ce qu'elle expose, ce qui est sensible. La première question tient dans une grille : qui peut faire quoi, sur quoi ?
Collaborateur · ses dossiers
- consulter, à définir
- modifier, à définir
- exporter, à définir
- supprimer, à définir
Responsable d'équipe · les dossiers de l'équipe
- consulter, à définir
- modifier, à définir
- exporter, à définir
- supprimer, à définir
Administrateur · selon les règles retenues
- consulter, à définir
- modifier, à définir
- exporter, à définir
- supprimer, à définir
Logiciel partenaire · par l'API
- consulter, à définir
- modifier, à définir
- exporter, à définir
- supprimer, à définir
À décrire ensemble
- Les applications concernéesmétier, portail client, back-office
- Les API exposées ou internesqui les appelle, depuis où
- Les données et opérations sensiblesce qui ne doit ni fuiter, ni être modifié à tort
- Les profils d'utilisateursrôles, équipes, partenaires
- Les contraintes d'architecturecode existant, hébergement, prestataires
- Les vérifications attenduestests, contre-vérification, audit éventuel