GET-Limites de sécurité des actions

GET-La sécurité de l’action part de l’hypothèse que URLs fuit.Les chaînes de requête peuvent saisir l’historique du navigateur, les journaux du serveur, les analyses, les référents, les caches, les captures d’écran, les signets, les transcriptions de discussion et les tickets d’assistance.

Contrôles requis#

1. Exigez idempotency_key ou nonce pour chaque exemple d’action GET compatible en écriture.
2. Rejetez les secrets, les jetons, les mots de passe, les clés API, les valeurs du porteur, les identifiants de compte, les identifiants médicaux, les données de paiement, les messages privés et les identifiants réglementés dans les chaînes de requête.
3. Exigez un consentement explicite pour la publication, les modifications de compte, les écritures dans le référentiel, les écritures dans la mémoire durable, les actions destructrices, les paiements, les données privées ou les contextes réglementés.
4. Appliquez des limites de débit, la gestion des relectures, la protection des robots d’exploration et la journalisation d’audit avant la gestion des actions.
5. Gardez l’action URLs en dehors de la promotion du plan du site et des invitations publiques aux robots d’exploration.
6. Renvoyez human_review_required ou rejected au lieu d’exécuter des requêtes ambiguës.

Règle de commande#

Les limites de sécurité et de consentement doivent apparaître avant les exemples qui pourraient être copiés en production. Les exemples sans limites proches sont des avertissements même lorsque l’exemple URL lui-même est de sécurité publique.

Exemples de réponses sûres#

{ "code": "human_review_required", "url": "https://example.org/review/agent_req_002" }
{ "code": "rejected", "url": "https://example.org/docs/get-action-security" }