פיתוח הרשאות וניהול משתמשים

מדוע אימות חתימת JWT הוא קריטי?

אנחנו נתקלים בזה באופן קבוע: לקוח שלנו עם JWT-טוקן עם תפקיד admin: false שינה אותו ל-admin: true — השרת קיבל את השינויים ללא בדיקת חתימה. זו לא מתקפה היפותטית: לספריית jwt ב-npm הייתה פרצת אבטחה שהתעלמה מאלגוריתם jwt. התוצאה — גישה מלאה לפונקציות אדמין לכל משתמש רשום. במשך 8 שנים בנינו עשרות מערכות הרשאות לפינטק, SaaS ומרקטפלייסים. מערכת ההרשאות המותאמת אישית שלנו (custom authorization system) מתחילה בכל פעם בביקורת קוד שחושפת לפחות חור קריטי אחד בלוגיקת ה-auth. הניסיון שלנו מלמד: הרשאות אמינות אינן "להוסיף ספרייה", אלא לתכנן ארכיטקטורה תוך התחשבות בכל וקטורי ההתקפה.

כיצד מערכת ההרשאות המותאמת אישית שלנו מונעת פרצות JWT

JWT מורכב משלושה חלקים: header (אלגוריתם), payload (נתונים), signature (חתימה). החתימה מאמתת את שלמות ה-payload — ללא בדיקתה זה פשוט מחרוזת base64 שכל אחד יכול לזייף. אנו מבטיחים שבפרויקט שלכם שום טוקן לא יעבור ללא ולידציה.

טעויות נפוצות שאנחנו מתקנים

• אחסון ב-localStorage — נגיש לכל JS בעמוד. מתקפת XSS גונבת את הטוקן. הסכימה שלנו: access token בזיכרון (משתנה מודולרי), refresh token בעוגיית httpOnly.
• Access token לטווח ארוך — 7 ימים ללא ביטול. דלף — 7 ימי גישה. תקן: 15 דקות ל-access, 30 יום ל-refresh עם רוטציה. בשימוש חוזר ב-refresh token ישן — מופעלת מתקפת Token Reuse Attack, וכל משפחת הטוקנים מבוטלת.
• סודות ב-payload — JWT אינו מצפין נתונים, רק חותם. סיסמאות, נתוני תשלום, מידע אישי — לא ב-JWT.
• אלגוריתם HS256 במקום RS256 — בארכיטקטורת מיקרוסרוויסים HS256 דורש סוד משותף. RS256 (א-סימטרי) מאפשר לשירותים לאמת טוקנים דרך מפתח ציבורי ללא גישה לסוד היוצר — זה מפחית ב-40% את סיכון הקומפרומטציה.

כיצד OAuth 2.0 ו-OpenID Connect עובדים בפועל

OAuth 2.0 — פרוטוקול הרשאות מואצלות, לא אימות זהות. "התחברות דרך Google" — זה OpenID Connect על גבי OAuth 2.0, שמוסיף id_token עם נתוני המשתמש. ה-flow הנכון היחיד ל-SPA ואפליקציות מובייל — Authorization Code Flow with PKCE. Implicit Flow מיושן ולא בטוח. PKCE מגן מפני יירוט קוד ההרשאה.

ביישום שרת OAuth אל תכתבו מאפס. Keycloak (open source, self-hosted), Auth0, Okta — פתרונות מוכנים. ל-Laravel — Passport או Sanctum. ל-Next.js — NextAuth.js עם תמיכה ב-50+ ספקים. למוצרי B2B עם לקוחות ארגוניים — SAML 2.0 SSO. @boxyhq/saml-jackson — ספריית Node.js לאדפטר SAML → OAuth2.

Sessions לעומת JWT: מתי לבחור מה

לרוב יישומי הווב, סשנים פשוטים ובטוחים יותר. JWT מוצדק כאשר ה-API נצרך על ידי לקוחות מובייל או בארכיטקטורת מיקרוסרוויסים. הצוות שלנו יישם את שתי הגישות — בכל פרויקט הבחירה נעשית לפי הדרישות הספציפיות.

RBAC, ABAC, ReBAC: איזה מודל גישה מתאים למערכת שלכם?

Role-Based Access Control — למשתמש יש תפקידים, לתפקידים יש הרשאות. יישום פשוט: user → roles → permissions. אבל ברגע שמופיעה הרשאה מבוססת-משאב ("משתמש יכול לערוך רק את הפוסטים שלו"), RBAC מסתבך.

Spatie Laravel Permission — התקן ל-Laravel: תפקידים והרשאות פולימורפיים, קאשינג, super-admin דרך gate. אינטגרציה עם Eloquent: $user->can('edit posts'), $user->hasRole('editor').

ABAC (Attribute-Based Access Control) — מדיניות המבוססת על תכונות של משתמש, משאב, סביבה. נדרש כשהחוקים מורכבים: "מנהל רואה הזמנות באזור שלו, אם ההזמנה נוצרה לפני יותר מ-24 שעות". Casbin — ספרייה חוצת-פלטפורמות ל-ABAC.

ReBAC (Relationship-Based Access Control) — המודל של Google Zanzibar. הגישה נקבעת על ידי גרף יחסים: "משתמש X — חבר בצוות Y, שיש לו גישה לפרויקט Z". OpenFGA — יישום open source של Okta. למערכות מולטי-טננט מורכבות, ReBAC נותן פי 3 פחות שגיאות גישה בהשוואה ל-RBAC (לפי נתוני הביקורות שלנו).

אימות דו-שלבי: TOTP, SMS, WebAuthn

TOTP (Google Authenticator, Authy) — התקן. ספריות: otplib (Node.js), pragmarx/google2fa (Laravel). קוד ה-QR בהגדרה מכיל סוד base32 — אם הוא נפרץ, הקוד ניתן לשחזור. אנו מאחסנים את הסוד מוצפן.

אימות SMS חלש יותר מ-TOTP בגלל SIM-סוופינג ואספקה לא אמינה, אבל משתמשים מפעילים אותו ברצון רב יותר. Email-OTP — פשרה בין אבטחה ל-UX.

WebAuthn (Passkeys) — ביומטריה או מפתח חומרה במקום סיסמה. מפתח פרטי במכשיר, מפתח ציבורי בשרת. אין סיסמה — אין דליפה. נתמך בכל הדפדפנים המודרניים. @simplewebauthn/server + @simplewebauthn/browser — ספריית Node.js טובה.

קודי גיבוי בהפעלת 2FA: 10 קודים חד-פעמיים לשחזור במקרה של אובדן טלפון. אנו מאחסנים אותם עם חשיש (bcrypt), ומציגים אותם רק בעת ההפקה.

פרצות נפוצות שאנחנו מבטלים

Broken Object Level Authorization (BOLA/IDOR): /api/orders/12345 מחזיר הזמנה ללא בדיקת שייכות למשתמש. פרצת ה-API הנפוצה ביותר לפי OWASP. כל בקשה למשאב — בדיקה דרך $user->can('view', $order).

Mass Assignment: User::create($request->all()) — משתמש שולח is_admin: true בגוף הבקשה. Laravel פותר דרך $fillable / $guarded, אבל לעיתים קרובות שוכחים.

Insecure CORS: Access-Control-Allow-Origin: * על API עם אימות עוגיות — credentials לא נשלחים עם מקור wildcard, אבל אם מישהו הגדיר Allow-Credentials: true + Allow-Origin: *, זו פרצה.

תהליך: מדרישות לייצור מאובטח

1. ביקורת הארכיטקטורה הנוכחית (אם הפרויקט כבר חי) — אנו מאתרים דליפות טוקנים, אלגוריתמים חלשים, חוסר rate limiting.
2. תכנון הסכימה — בחירה בין סשנים ל-JWT, מבנה תפקידים והרשאות, ספקי OAuth, תוכנית 2FA.
3. יישום — אנו כותבים קוד עם כיסוי בדיקות (unit + integration + security).
4. פנטסט — חובה למוצרים עם נתונים פיננסיים או אישיים. אנו מבצעים בדיקות אוטומטיות וידניות.
5. תיעוד — תרשים ארכיטקטורה, הוראות פריסה, תיאור נקודות קצה של API להרשאות.
6. פריסה וניטור — הגדרת התראות על פעילות חשודה (התחברויות מרובות, שימוש בטוקנים מיושנים).
7. תמיכה לאחר השחרור — 30 ימי תיקונים וייעוץ.

מה כלול בתוצר הסופי

• תיעוד ארכיטקטוני (דיאגרמות, נימוקי בחירה)
• קוד מקור עם הערות
• בדיקות מודולריות ואינטגרציה (≥80% כיסוי)
• אינטגרציית CI/CD (GitHub Actions, GitLab CI)
• הוראות פריסה (Docker, משתני env)
• אתר הדגמה לבדיקות
• 30 ימי תמיכה לאחר השחרור

לוח זמנים והערכת פרויקט

העלות מחושבת באופן אישי. אנו נעריך את הפרויקט שלכם — צרו קשר כדי לדון בפרטים ולקבל ייעוץ. הלקוחות שלנו מקבלים מערכת הרשאות מותאמת אישית שעוברת פנטסט מהניסיון הראשון. הזמינו ביקורת של לוגיקת ה-auth הנוכחית או פיתוח מאפס — כתבו לנו.