Un service de courrier temporaire possède plusieurs charges de travail différentes : génération d'adresses, affichage du courrier, ouverture des corps de message, réception du trafic SMTP et exécution de tâches d'administration. Une limite globale unique ne peut pas exprimer tous leurs risques.
Effectuez d'abord les contrôles bon marché
Validez la route, la méthode, la taille des entrées et les informations d'identification requises avant d'effectuer des opérations coûteuses sur la base de données ou le stockage d'objets. Utilisez des caches limités pour les métadonnées appropriées et évitez de créer un état illimité par clé à partir d'identifiants non vérifiés. Les vérifications d'accès doivent toujours s'appliquer aux réponses mises en cache.
Allouez un budget à chaque charge de travail
| Charge de travail | Contrôle utile |
|---|---|
| Interrogation de boîte de réception anonyme | Budgets de requêtes, consignes de temporisation et validation de session. |
| Utilisation d'API authentifiée | Limites associées aux informations d'identification et à l'opération. |
| Ingestion SMTP | Limites de connexion, de taille de message et de destinataires. |
| Tâches de maintenance | Petits lots et concurrence limitée. |
Distinguer un pic d'un abus continu
Un client légitime peut réessayer après une défaillance réseau. Enregistrez suffisamment d'informations pour différencier ce pic d'un trafic soutenu qui ignore les limites. Les réponses graduées peuvent inclure le ralentissement des requêtes, le rejet temporaire ou la révocation des informations d'identification lorsque les preuves et la politique le justifient.
Vérifiez le chemin d'échec
Testez qu'une requête rejetée n'exécute pas tout de même le travail coûteux. Confirmez que les clients bien comportés comprennent les réponses de nouvelle tentative et que l'accès privilégié à la boîte de réception ne peut pas être contourné en modifiant le point de terminaison.
Ceci est une liste de contrôle architecturale, et non une affirmation selon laquelle chaque contrôle est activé sur chaque déploiement. Les limites de service actuelles et les règles d'accès doivent être tirées de la documentation du site et des réponses de l'API.