GET-La sécurité de l’action commence en supposant une fuite URLs.Les chaînes de requête peuvent apparaître dans l’historique du navigateur, les journaux du serveur, les analyses, les référents, les caches, les captures d’écran et les tickets d’assistance.
Liste de contrôle de sécurité
- Exiger une clé d’idempotence et rejeter la relecture avec des paramètres contradictoires.
- N’incluez jamais de secrets, de jetons, de mots de passe, de clés API, d’identifiants de patients, d’identifiants de compte, de données de paiement, de messages privés ou de données réglementées dans la chaîne de requête.
- Utilisez un point de terminaison POST correspondant pour les clients L2+ et toutes les actions riches ou sensibles.
- Exiger le consentement humain pour la publication, les écritures dans le référentiel, les modifications de compte, les actions destructrices, les écritures en mémoire durable, les actions financières ou les contextes réglementés.
- Appliquez des limites de débit strictes, une protection contre les robots d’exploration et une détection des abus avant l’exécution de l’action.
- Enregistrez des preuves d’audit de sécurité publique sans stocker de secrets bruts ou de documents de requête privés.
- Gardez les points de terminaison de l’action hors des entrées publiques du plan de site et des invitations à l’index de recherche.
- Déclarez les exigences GET dynamiques en direct et fournissez une solution de secours pour les récupérateurs indexés uniquement.
- Renvoyez une révision URL ou un bloqueur au lieu d’exécuter des requêtes ambiguës.
Exemples de rejet
?token=...,?api_key=...,?password=...ou valeurs de type support.- Identifiants médicaux ou réglementés portés en URLs.
- Destructeur, paiement, publication ou changement de compte en un clic URLs sans chemin révisé plus fort.
Valeur par défaut sûre
En cas de doute, effectuez la partie en lecture seule, renvoyez une révision lisible par l’homme URL et exigez POST JSON ou l’approbation humaine avant l’exécution.