אבטחת API - הבסיס שכל מפתח צריך¶
בניתם API שעובד. הוא מחזיר את הנתונים הנכונים, הבדיקות עוברות, הכל נראה מוכן. אבל "עובד" ו"מאובטח" הן שתי שאלות שונות לגמרי, וברוב הפעמים API נפרץ לא בגלל חולשה מתוחכמת, אלא בגלל שאחד מכמה יסודות בסיסיים פשוט לא טופל. זו רשימת הבדיקה שכל מפתח בקאנד צריך לעבור לפני שה-API שלו יוצא לייצור.
אימות מול הרשאה - שני דברים שונים לגמרי¶
הטעות הראשונה והנפוצה ביותר היא לבלבל בין השניים. אימות (authentication) עונה על השאלה "מי אתה" - האם המשתמש הצליח להוכיח שהוא מי שהוא טוען שהוא, בדרך כלל דרך סיסמה או טוקן. הרשאה (authorization) עונה על שאלה אחרת לגמרי - "מה מותר לך לעשות". API יכול לאמת משתמש בהצלחה, ועדיין לטעות ולתת לו גישה לנתונים שלא שייכים לו.
הדוגמה הקלאסית היא endpoint כמו /orders/123 שבודק רק שהמשתמש מחובר, בלי לבדוק שההזמנה 123 באמת שייכת לו. משתמש מחובר יכול פשוט לשנות את המספר בכתובת ולראות הזמנות של אנשים אחרים. לכל endpoint שמחזיר או משנה נתונים ספציפיים, חובה לבדוק גם בעלות, לא רק חיבור תקין.
ולידציית קלט - לעולם אל תסמכו על מה שמגיע מבחוץ¶
כל קלט שמגיע מבחוץ - גוף בקשה, פרמטרים בכתובת, headers - צריך להיבדק לפני שהוא נכנס ללוגיקה של המערכת. זה כולל בדיקת סוג נתונים (מספר הוא באמת מספר), טווח סביר (גיל לא יכול להיות מינוס חמש), ואורך מחרוזת סביר. ולידציה חלשה היא השער הראשון לכל התקפה - הזרקת SQL, קלט זדוני שגורם לשגיאות לא צפויות, או פשוט נתונים פגומים שמשבשים את המערכת בהמשך.
הכלל הפשוט הוא לבדוק את הקלט לפי מה שכן מותר (allowlist), ולא לנסות לחסום כל מה שאסור (blocklist) - הרבה יותר קל להגדיר בדיוק מה תקין מאשר לנחש כל וריאציה אפשרית של קלט זדוני.
HTTPS בלי יוצא מן הכלל¶
כל תעבורה בין הקליינט לשרת חייבת לעבור דרך HTTPS, בלי חריגים, גם ל-endpoints שנראים "לא רגישים". בלי הצפנה, כל מי שיושב על הרשת בין המשתמש לשרת - רשת WiFi ציבורית, ספק אינטרנט, כל גורם באמצע - יכול לקרוא את התעבורה כמו שהיא, כולל טוקני אימות וסיסמאות. הגדרת HTTPS היום קלה וזולה, ואין שום סיבה טובה לוותר עליה אפילו ב-endpoint אחד.
הגבלת קצב - הגנה מפני עומס וניצול לרעה¶
API בלי הגבלת קצב חשוף לניצול - מישהו יכול לשלוח בקשות בקצב שמציף את השרת, או לנסות לנחש סיסמאות במהירות דרך endpoint ההתחברות. הגבלת בקשות לפי משתמש או כתובת IP היא הגנה בסיסית שמונעת בדיוק את התרחישים האלה, ולא צריכה להיות תכונה שמוסיפים "כשיהיה זמן" - היא שייכת לשלב התכנון הראשוני.
הודעות שגיאה שלא מספרות יותר מדי¶
כשמשהו נכשל, קל לרצות להחזיר הודעת שגיאה מפורטת שעוזרת בדיבוג - אבל הודעה מפורטת מדי חושפת מידע פנימי לכל מי שרואה אותה, לא רק לכם. הודעת שגיאה שחושפת גרסת מסד נתונים, מבנה טבלה, או נתיב קובץ פנימי, נותנת לתוקף פוטנציאלי מפת דרכים למערכת. ההפרדה הנכונה היא לתעד את הפרטים המלאים בלוגים הפנימיים שלכם, ולהחזיר למשתמש הודעה כללית וברורה, בלי פרטים טכניים.
לוגים ומעקב - לדעת שקרה משהו¶
גם עם כל ההגנות הקודמות, שום מערכת לא חסינה לגמרי. לכן חשוב לתעד ניסיונות התחברות כושלים, בקשות שנדחו בגלל הרשאה חסרה, ופעילות חריגה - כדי שתדעו לזהות ניסיון תקיפה בזמן אמת, במקום לגלות אותו רק אחרי שהנזק כבר נגרם.
איך לומדים ליישם את כל זה בפועל¶
רשימת הבדיקה הזאת נשמעת ברורה על הנייר, אבל ליישם אותה נכון בפרויקט אמיתי - עם כל הפרטים הקטנים שקל לפספס - זה נלמד הכי טוב תוך כדי בניית API אמיתי. בקורס צד-שרת בונים API עם כל שכבות האבטחה האלה מההתחלה, לא כתוספת בסוף.
בונים API ולא בטוחים אם כיסיתם את כל הבסיס? זה בדיוק סוג השאלה שכדאי לשאול בקהילה שלנו.
לסיכום¶
אבטחת API לא מתחילה בטכניקות מתוחכמות, היא מתחילה בכמה יסודות פשוטים שקל לפספס תחת לחץ זמן - הפרדה נכונה בין אימות להרשאה, ולידציית קלט קפדנית, HTTPS בכל מקום, הגבלת קצב, והודעות שגיאה זהירות. רוב הפריצות ל-API לא קורות בגלל חולשה נדירה, הן קורות בגלל אחד מהיסודות האלה שדולג עליו.