זיהוי הגבול שהושג
HTTP 429 מציין עודף בקשות ועשוי לכלול Retry-After. הספירה וההיקף תלויים בשירות. ממוצע נמוך אינו מונע חריגה בחלון קצר.
| מושג | מה מוגבל | פעולה מועילה |
|---|---|---|
| מכסה | נפח בתקופה | תכנון תקציב משותף. |
| קצב | כניסות בחלון קצר | פיזור התחלות. |
| מקביליות | פעולות פעילות | הגבלת עבודה בו־זמנית. |
| Retry-After: 120 | המתנה של 120 שניות | בדיקת הזמן הכולל ובטיחות החזרה. |
תכנון העומס המותר
- בדקו מפתח ספירה: חשבון, פרויקט, משתמש או נתיב. בדקו אזור זמן לאיפוס, עלות פעולה ותקציב משותף.
- מתנו פרצים בתור מוגבל והגבילו בנפרד עבודה פעילה. העבירו ביטולים והסירו משימות שאינן נחוצות עוד.
- פרשו Retry-After כתאריך HTTP או המתנה בשניות. כבדו אותו במסגרת הזמן הכולל וקבעו המתנה מוגבלת כשאינו קיים.
חזרה בלי לעקוף הגנה
429 אינו מוכיח שבטוח לחזור על הפעולה. בדקו אידמפוטנטיות, זמן כולל ומספר ניסיונות. מדדו דחיות ואורך תור; אם ביקוש קבוע חורג מהחוזה צמצמו צורך או תאמו קיבולת.
מקורות ראשוניים
הפוך את ניצול לרעה של מגבלות קצב לניתן לצפייה.
מגבלות בקשות פועלות טוב יותר כאשר הן מבחינות בין שימוש לגיטימי להתנהגות חריגה ומייצרות אירוע בר-פירוש. קודי שגיאה בלבד עשויים להסתיר את תחילתו, משכו והישג ידו של דפוס ניצול לרעה.
- רישום סף, החלטה, מסלול והקשר מינימלי ללא סודות.
- קישור בין דחיות חוזרות ונשנות לבין השפעות על משתמשים לגיטימיים.
- בדיקה האם התראות מובילות לחקירה או כוונון פרופורציונלי.
מקור ראשוני: ACSC and partners — Event logging and threat detection. שיטה קשורה: קריאת המדריך המעשי.