Rate limiting: הבקרה שכולם מסכימים עליה ואף אחד לא מיישם

Read this article in English

בתוך ים הוולידציות וההצפנות, אחד הדברים הכי קריטיים – ועדיין הכי לא מיושמים – זה מנגנון הגבלת קצב (rate limiting). כל API, לא משנה כמה הוא סגור ומבוקר, עלול להפוך לפגיע ברגע שמוותרים על הגבלת קצב. ובמיוחד אם יש מתודות שרגישות לשימוש חוזר בקצב גבוה.

אתחיל מדוגמה שנתקלתי בה – אתר הרשמה סטנדרטי, שבו כל POST /register מייצר משתמש חדש ושולח הודעה למייל. במשך חודשים לאף אחד לא הפריע שאין הגבלה על מספר בקשות בדקה. עד שיום אחד בוט פשוט ירה עשרות אלפי בקשות והציף את הדוא״ל, יצר עומס ב-DB, ובעיקר – חילץ מאות שמות משתמשים אמיתיים מהתשובות של ה-API (username taken וכו').

אבל הבעיה היא לא רק התקפות brute force. בלי rate limit כל סקרייפר או תוקף יכול פשוט לרוץ ברקע, לבדוק קיומם של משתמשים, לפרוץ עם dictionary attack על סיסמאות פשוטות, או לבדוק אם טוקן שדלף עדיין בתוקף.

ה-bypass שצריך לצפות לו

דוגמה פופולרית: הרבה מערכות בודקות קצב לפי IP, אבל מתעלמות מ-headers כמו X-Forwarded-For, או לא סופרות משתמשים עם session או token שונה. התוקף יפעיל עשרות proxies, ישנה header, או אפילו יפתח עשרות חשבונות דמה – ויעקוף כל בדיקה פשוטה.

איך נראה יישום נכון

Rate limiting צריך להיבדק בכמה שכבות – IP, session, משתמש, ואפילו מסלול פעולה (endpoint ספציפי). בפועל, יישום נכון כולל:

• עדכון מיידי של counters – לא פעם בדקה, אלא real time.
• בלוק למספר דקות לאחר חריגה.
• שליחת alert במקרה של חריגה חריגה (pattern לא רגיל).
• הצגת הודעת שגיאה שלא מגלה יותר מדי – לא "נחסמת כי ניסית יותר מדי", אלא הודעה גנרית.
• בדיקות קצה על כל API – גם פנימיים, לא רק חיצוניים.

מה לבדוק בפנטסט

• האם אפשר לשלוח 10,000 בקשות דרך 10 sessionIds שונים ולא להיחסם?
• מה קורה אם מחליפים header של IP?
• האם rate limit נשמר גם ב-POST וגם ב-GET?
• האם הוא מופעל גם על endpoints שלא מיועדים לפרונטנד?

ראיתי מערכות ענק שנפלו על זה – עד שהגיע בוט וניצל בדיוק את אותו חור קטן שאף אחד לא בדק.

והמלצה כללית ממני – לא להסתפק בספרייה חיצונית, תמיד לבדוק integration עם הלוגיקה העסקית של המערכת.

פוסט זה פורסם לראשונה בלינקדאין בתאריך 2025-07-21. — ארז מטולה