כשהמנעול פתוח, למה Authentication ו-Authorization הם עדיין הבעיה מספר 1
OWASP Top 10:2025 פורסם בתחילת 2025. המקום הראשון, Broken Access Control, שוב. המקום השביעי, Authentication Failures. שניהם יחד אחראיים לרוב פריצות הנתונים המשמעותיות שקרו בשנים האחרונות. זה לא כי הפתרונות לא קיימים, JWT, OAuth2, RBAC כולם תיעוד ב-open source. זה כי מפתחים שוב ושוב עושים את אותן שלוש טעויות. Claude יכול לשמש כ-security reviewer שקורא את הקוד שלך, מוצא את הפרצות, ומסביר בדיוק מה לתקן.
Authentication לעומת Authorization, שני מושגים שמתבלבלים כל הזמן
ההבחנה פשוטה אבל קריטית: Authentication = מי אתה? (login, JWT verification, session check). Authorization = מה מותר לך לעשות? (האם מותר לך לגשת ל-/api/reports/42? לעדכן חשבון משתמש אחר?). הכישלון הנפוץ: מפתחים בודקים את ה-Authentication ("האם המשתמש מחובר?") אבל שוכחים את ה-Authorization ("האם המשתמש הזה מורשה ל-resource הזה?").
זו הבעיה הקלאסית של IDOR (Insecure Direct Object Reference): endpoint /api/orders/1234 מחזיר הזמנה לכל משתמש מחובר, גם אם ההזמנה שייכת למשתמש אחר. סטארטאפ ישראלי בתחום ה-fintech גילה ב-2023 שכל לקוח יכול לראות את הזמנות הלקוחות האחרים פשוט על ידי שינוי ה-ID ב-URL. 40,000 לקוחות נחשפו.
| מושג | שאלה שנשאלת | דוגמה | כלי נפוץ |
|---|---|---|---|
| Authentication | מי אתה? | האם ה-JWT תקף? | JWT, Sessions, OAuth2 |
| Authorization | מה מותר לך? | האם מותר לך ל-/admin? | RBAC, ABAC, Middleware |
| IDOR Protection | האם זה שלך? | order.userId === req.user.id? | Ownership check ב-DB query |
JWT, שלוש הטעויות שעושים שוב ושוב
JWT (JSON Web Token) הוא הסטנדרט הנפוץ ביותר ל-stateless authentication. הוא מורכב מ-Header, Payload, ו-Signature. הבעיות לא ב-JWT עצמו, הן ב-implementation.
- Algorithm Confusion: ספריות ישנות קיבלו JWT עם
algorithm: "none", ללא חתימה בכלל. פרצה שמאפשרת לכל אחד לזייף token. תמיד הגדר algorithm explicitly ב-verify:jwt.verify(token, secret, { algorithms: ['RS256'] }). - חסר expiry: token ללא
expclaim תקף לנצח. אם נגנב, לתוקף יש גישה לנצח. Access token: 15 דקות. Refresh token: 7 ימים עם rotation. - localStorage במקום httpOnly cookie: JavaScript יכול לקרוא localStorage, כלומר כל XSS attack גונב את ה-token מיידית. httpOnly cookie = JavaScript לא יכול לגשת אליו בכלל.
RBAC, בניית מערכת הרשאות שלא תישבר
RBAC (Role-Based Access Control) הוא הגישה הנפוצה ביותר לניהול הרשאות. העיקרון: הגדר roles, הגדר permissions לכל role, בדוק בכל request. שלושה כללים שחייבים לאמץ:
- Fail Secure, ברירת מחדל: deny. כל resource חדש שנוסף אוטומטית חסום לכולם עד שמגדירים explicitly מי מורשה. הגישה ההפוכה (ברירת מחדל: allow) היא פצצת זמן.
- Least Privilege. כל role מקבל רק את ההרשאה המינימלית הדרושה. אל תיתן ל-manager הרשאות שרלוונטיות ל-super_admin.
- Logging של כל ניסיון גישה. גם מורשה וגם לא-מורשה. בלי audit trail אי אפשר לחקור incident.
כשלונות ב-RBAC של אגף ה-IT בחברות גדולות בישראל נובעים לרוב מ"role bloat": כל עובד מקבל role חדש כי "זה יותר קל", עד שיש 47 roles שאף אחד לא מבין. Claude יכול לנתח permissions matrix קיים ולזהות overlaps, redundancies, ו-privilege escalation paths.
OAuth 2.1 ו-PKCE, מה השתנה ב-2025
RFC 9700 פורסם בינואר 2025, עשר שנות לקחים מ-OAuth 2.0 בפורמט Best Current Practice. ה-takeaway המרכזי: OAuth 2.1 עושה PKCE חובה לכל client, כולל server-side web apps, לא רק mobile. ו-Implicit Flow הוסר לחלוטין מהספציפיקציה.
למה PKCE חשוב? בלי PKCE, authorization code שנגנב באמצע (man-in-the-middle) יכול להחלף ב-token. PKCE מוסיף code_verifier ו-code_challenge שמבטיחים שרק הclient שהתחיל את ה-flow יכול לסיים אותו.
בקש מ-Claude: "הסבר מה ההבדל בין Authorization Code Flow עם PKCE לבין Implicit Flow שהוסר מ-OAuth 2.1. כתוב Node.js implementation מלא של PKCE flow עם state parameter, nonce, ו-CSRF protection."
איך לבקש מ-Claude security review על auth code
Claude מצוין בניתוח authentication code כשנותנים לו הקשר מספיק. Anthropic עצמה השתמשה ב-Claude Code לסריקת open-source codebases ומצאה מעל 500 vulnerabilities שהיו שם עשרות שנים. הגישה הטובה ביותר:
- הדבק את ה-auth middleware המלא, לא קטעים. Claude צריך לראות את כל ה-flow.
- תן context על הארכיטקטורה, "זה Node.js + Express + Postgres, JWT stateless, SPA בצד הלקוח".
- בקש role-play כ-attacker, "תנסה לפרוץ את ה-auth שלי. מה תנסה ראשון?"
- בקש קוד מתוקן, לא רק רשימת בעיות, גם הפתרון המלא.
טעויות נפוצות ואיך להימנע מהן
- ערבוב Authentication ו-Authorization: לבדוק שהמשתמש מחובר (authentication) זה לא מספיק. כל endpoint צריך גם לבדוק שהמשתמש מורשה לאותו resource ספציפי (authorization + ownership check).
- Implicit OAuth Flow ב-2025: Implicit Flow הוסר מ-OAuth 2.1 ומ-RFC 9700. אם עדיין משתמשים בו, עוברים ל-Authorization Code + PKCE. זה לא רק המלצה, זה הסטנדרט החדש.
- Error messages verbose: הודעת שגיאה "הסיסמה שגויה" חושפת שה-username קיים. תמיד: "שם משתמש או סיסמה שגויים", הודעה גנרית שלא מסייעת לתוקף.
- Session שלא מתפוגגת: "Remember me" שנשאר 5 שנים הוא session token שיחיה 5 שנים אם נגנב. Access tokens: 15 דקות. Refresh tokens: 7-30 ימים עם rotation.
סיכום, מה לזכור
- Authentication (מי אתה) ו-Authorization (מה מותר לך) הם שני בדיקות נפרדות, כל endpoint צריך את שתיהן.
- JWT: algorithm explicit, expiry קצר, httpOnly cookie, jti לrevocation.
- RBAC: ברירת מחדל deny, least privilege, audit logging.
- OAuth 2.1 + RFC 9700 (2025): PKCE חובה לכולם, Implicit Flow הוסר.
- Claude יכול לסרוק את ה-auth middleware שלך ולמצוא פרצות, תן לו את הקוד המלא עם context על הארכיטקטורה.
מקורות: OWASP Top 10:2025 | RFC 9700, OAuth 2.0 Security Best Current Practice | OAuth 2.1, What's New | Claude Code Security, Anthropic
