יסודות אבטחת אפליקציות ווב: רשימת בדיקה שכל בעל עסק צריך לדרוש

אבטחת אפליקציית ווב היא לא עניין של לשכור האקר שיבדוק את האתר שלכם או לקרוא תיעוד OWASP — זה עניין של לוודא שצוות הפיתוח שלכם כיסה חמישה יסודות: סיסמאות אף פעם לא נשמרות כטקסט גלוי, כל קלט מהמשתמש מטופל כלא אמין, יש הגבלת קצב על בקשות שמונעת ניצול לרעה, כותרות אבטחה (security headers) מופעלות, והסשנים פגים ומתבטלים כמו שצריך. אתם לא צריכים להבין קוד כדי לוודא שהדברים האלה קיימים — אתם צריכים לדעת אילו שאלות לשאול, ואיך אמורה להישמע תשובה נכונה. הרשימה הזו נותנת לכם בדיוק את זה, בלי צורך ברקע טכני.

אימות משתמשים נכון: סיסמאות שלא נשמרות בטקסט גלוי, אף פעם

אם צוות הפיתוח שלכם יכול לשלוף את הסיסמה של משתמש פשוט על ידי שאילתה למסד הנתונים — זה דגל אדום מיידי. סיסמאות צריכות להיות מוצפנות (hashed) באלגוריתם מודרני כמו bcrypt או argon2, עם salt אקראי כדי ששתי סיסמאות זהות לעולם לא ייצרו את אותו ערך שמור. המשמעות היא שגם אם מסד הנתונים ייחשף יום אחד, הסיסמאות בו חסרות ערך מעשי למי שגנב אותן. באותה מידה חשוב: סשנים וטוקנים של התחברות צריכים לפוג, להתבטל מיידית בהתנתקות, ולהשתמש בעוגיות httpOnly מאובטחות כדי שקוד שרץ בדפדפן לא יוכל לגנוב אותם.

בדיקת קלט: תתייחסו לכל מה שמשתמש מקליד כלא אמין

כל תיבת טקסט, שדה העלאת קובץ ופרמטר בכתובת URL באתר שלכם הוא דלת פוטנציאלית. העיקרון "אף פעם אל תסמכו על קלט משתמש" אומר שהאפליקציה בודקת ומנקה כל פיסת מידע שנכנסת אליה — בצד השרת, לא רק בדפדפן, כי בדיקה שנעשית רק בדפדפן אפשר לעקוף בקלות על ידי כל מי שיודע איך. התעלמות מזה היא בדיוק מה שפותח את הדלת להתקפות SQL injection (הטעיית מסד הנתונים להריץ פקודות שלא נועדו לו) ו-XSS (הזרקת קוד זדוני לדפים שמשתמשים אחרים רואים). בדיקת קלט היא לא משימה חד-פעמית — היא משמעת שמיושמת על כל טופס וכל נקודת API שהאפליקציה חושפת.

הגבלת קצב: עוצרים ניצול לרעה לפני שהוא מתחיל

בלי הגבלה על כמות הבקשות שמבקר אחד יכול לשלוח, האפליקציה שלכם חשופה לשלוש בעיות נפוצות: התקפות brute-force שמנחשות סיסמה על ידי ניסיון אלפי צירופים, בוטים שגורפים (scraping) את התוכן או המחירים שלכם בקנה מידה גדול, ופשוט עומס שמאט את האתר לכולם. הגבלת קצב (rate limiting) קובעת תקרה לכמות ניסיונות ההתחברות, שליחת הטפסים או קריאות ה-API שכתובת IP אחת או חשבון אחד יכולים לבצע בחלון זמן נתון, וחוסמת או מאטה כל מי שחוצה אותה.

כותרות אבטחה: הגדרות קטנות, הגנה אמיתית

כותרות אבטחה (security headers) הן הוראות שהשרת שלכם שולח לדפדפן לגבי איך להתנהג, והן סוגרות קטגוריות שלמות של התקפות כמעט בלי עלות הנדסית. כותרת Content-Security-Policy מונעת הרצת סקריפטים זדוניים בדפים שלכם. HSTS מכריחה כל מבקר להתחבר דרך ערוץ מוצפן. X-Frame-Options ו-X-Content-Type-Options מונעות מהאתר שלכם להיות מוטמע בתוך פריים מוסווה או שהקבצים שלו ייקראו בצורה שגויה על ידי הדפדפן. אתם לא צריכים להבין את התחביר שלהן — רק לוודא שהצוות שלכם באמת הפעיל אותן.

איך לשאול את צוות הפיתוח את השאלות הנכונות

אתם לא צריכים רקע טכני כדי לוודא שהעבודה הזו נעשתה — אתם צריכים לשאול שאלות סגורות וממוקדות, ולצפות לתשובות ישירות באותה רמת בהירות:

• האם הסיסמאות מוצפנות עם salt, או שמישהו עם גישה למסד הנתונים יכול לקרוא אותן ישירות?
• האם כל טופס וקלט API נבדקים בצד השרת, לא רק בדפדפן?
• האם יש הגבלת קצב על התחברות, הרשמה וחיפוש?
• האם כותרות אבטחה כמו CSP ו-HSTS מופעלות — ואוכל לבדוק זאת בעצמי בכלי בדיקה חינמי באינטרנט?
• האם סשנים פגים, והאם הם מתבטלים מיידית בהתנתקות או בשינוי סיסמה?
• מתי נבדק הנושא הזה לאחרונה, ועל ידי מי?