Security Specialist

🔒 Security Specialist Skill

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

העיקרון המנחה: אבטחה טובה היא אבטחה פשוטה. אם זה מסובך מדי - לא תעשה את זה.

⚠️ למה אבטחה חשובה?

עלות ממוצעת של פריצה ב-2025: $4.45 מיליון

גם אם אתה סטארטאפ קטן:

• האקרים מחפשים מטרות קלות - לא רק חברות גדולות
• API key חשוף יכול לעלות אלפי דולרים בחיובי ענן
• דליפת מידע הורסת אמון של משתמשים
• GDPR/HIPAA - קנסות כואבים על הפרת פרטיות

🎯 OWASP Top 10 - הסיכונים העיקריים

מהו OWASP?

ארגון שמפרסם רשימה של 10 הסיכונים הנפוצים ביותר באפליקציות ווב.

הסיכונים בשפה פשוטה

🔑 שלב 1: ניהול API Keys ו-Secrets

❌ הטעויות הנפוצות ביותר

✅ מה לעשות נכון

┌─────────────────────────────────────────────────────────────┐
│                    איפה לשמור Secrets?                      │
├─────────────────────────────────────────────────────────────┤
│  ✅ Environment Variables (.env)                            │
│  ✅ Secret Manager (Supabase Vault, Railway Variables)      │
│  ✅ .env.local (לא נכנס ל-Git)                              │
│                                                             │
│  ❌ בקוד עצמו                                               │
│  ❌ ב-Git repository                                        │
│  ❌ בצד הלקוח (Frontend)                                    │
└─────────────────────────────────────────────────────────────┘

קובץ .gitignore - חובה!

# Secrets - לעולם לא ל-Git!
.env
.env.local
.env.production
*.pem
*.key
secrets/

# Supabase
supabase/.env

קובץ .env לדוגמה

# .env.example (זה כן נכנס ל-Git - בלי ערכים אמיתיים!)
SUPABASE_URL=your_supabase_url_here
SUPABASE_ANON_KEY=your_anon_key_here
SUPABASE_SERVICE_ROLE_KEY=your_service_role_key_here
OPENAI_API_KEY=your_openai_key_here

⚠️ Supabase Keys - הבדל קריטי!

כלל זהב: service_role key עוקף את כל האבטחה. אם הוא נחשף - הכל חשוף.

🛡️ שלב 2: אבטחה ב-Supabase (RLS)

מהו RLS? (Row Level Security)

מטאפורה: תארו לכם בניין משרדים. RLS זה כמו כרטיס כניסה שמאפשר לכם להיכנס רק לחדרים שאתם מורשים אליהם.

בלי RLS: כל מי שיש לו את המפתח (anon key) יכול לראות הכל. עם RLS: כל משתמש רואה רק את המידע שלו.

איך זה עובד

-- שלב 1: הפעלת RLS על טבלה
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

-- שלב 2: יצירת Policy - מי יכול לראות מה
CREATE POLICY "Users can view own profile" 
ON profiles FOR SELECT 
USING (auth.uid() = user_id);

-- שלב 3: Policy לעדכון
CREATE POLICY "Users can update own profile" 
ON profiles FOR UPDATE 
USING (auth.uid() = user_id);

תבניות RLS נפוצות

צ'קליסט RLS

• RLS מופעל על כל טבלה שיש בה מידע משתמשים
• יש Policy לכל פעולה (SELECT, INSERT, UPDATE, DELETE)
• בדקתי שמשתמש לא יכול לראות מידע של אחרים
• service_role key משמש רק ב-Backend

🔐 שלב 3: אימות והרשאות (Authentication)

מה Supabase Auth נותן לך

┌─────────────────────────────────────────────────────────────┐
│                    Supabase Auth                            │
├─────────────────────────────────────────────────────────────┤
│  ✅ הרשמה עם Email/Password                                 │
│  ✅ OAuth (Google, GitHub, etc.)                            │
│  ✅ אימות Email                                             │
│  ✅ שחזור סיסמה                                             │
│  ✅ JWT Tokens אוטומטי                                      │
│  ✅ MFA (Two-Factor Authentication)                         │
└─────────────────────────────────────────────────────────────┘

הגדרות מומלצות

קוד לדוגמה - בדיקת משתמש מחובר

// Frontend - React
import { useEffect, useState } from 'react'
import { supabase } from './supabaseClient'

function ProtectedPage() {
  const [user, setUser] = useState(null)
  const [loading, setLoading] = useState(true)

  useEffect(() => {
    // בדיקת משתמש נוכחי
    supabase.auth.getUser().then(({ data: { user } }) => {
      setUser(user)
      setLoading(false)
    })

    // האזנה לשינויים
    const { data: { subscription } } = supabase.auth.onAuthStateChange(
      (_event, session) => {
        setUser(session?.user ?? null)
      }
    )

    return () => subscription.unsubscribe()
  }, [])

  if (loading) return <div>Loading...</div>
  if (!user) return <div>Please log in</div>
  
  return <div>Welcome, {user.email}!</div>
}

🧹 שלב 4: Input Validation (אימות קלט)

למה זה חשוב?

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

סוגי התקפות שאימות מונע

כללים בסיסיים

✅ תמיד לאמת בצד השרת (Backend)
✅ לעולם לא לסמוך על קלט מהמשתמש
✅ להשתמש ב-Parameterized Queries
✅ לסנן תווים מיוחדים
✅ להגביל אורך קלט

קוד לדוגמה - FastAPI

from pydantic import BaseModel, EmailStr, validator
from fastapi import FastAPI, HTTPException

app = FastAPI()

class UserCreate(BaseModel):
    email: EmailStr  # מאמת אוטומטית פורמט email
    name: str
    
    @validator('name')
    def name_must_be_valid(cls, v):
        if len(v) < 2 or len(v) > 50:
            raise ValueError('Name must be 2-50 characters')
        if not v.replace(' ', '').isalpha():
            raise ValueError('Name must contain only letters')
        return v.strip()

@app.post("/users")
async def create_user(user: UserCreate):
    # הקלט כבר מאומת בזכות Pydantic!
    # ... יצירת משתמש
    return {"message": "User created"}

🔒 שלב 5: HTTPS והצפנה

HTTPS - חובה!

מה צריך לעשות?

בהוסטינג מודרני (Vercel, Railway, Supabase) - אוטומטי!

אבל תוודא:

• כל הבקשות עוברות ב-HTTPS
• HTTP מופנה אוטומטית ל-HTTPS
• TLS 1.2 לפחות (עדיף 1.3)

הצפנת מידע רגיש

┌─────────────────────────────────────────────────────────────┐
│           מה להצפין?                                        │
├─────────────────────────────────────────────────────────────┤
│  ✅ סיסמאות (bcrypt - Supabase עושה אוטומטית)              │
│  ✅ מידע רפואי / פיננסי                                     │
│  ✅ מספרי כרטיס אשראי (או השתמש ב-Stripe!)                  │
│  ✅ מידע אישי רגיש (PII)                                    │
│                                                             │
│  ℹ️ Supabase מצפין אוטומטית את כל ה-DB ב-AES-256           │
└─────────────────────────────────────────────────────────────┘

🤖 שלב 6: אבטחה בעבודה עם AI (Claude Code)

⚠️ אזהרה חשובה

"אם אתה אומר ל-AI לגרום למשהו לעבוד, הוא עלול להסיר את בדיקות האבטחה שמגינות עליך." — Bill Harmer, CISO Supabase

מה AI עלול לעשות בטעות

כללים לעבודה בטוחה עם AI

# ב-CLAUDE.md שלך, הוסף:

## Security Rules - DO NOT BYPASS
- Never disable RLS on any table
- Never expose service_role key in frontend
- Always validate user input
- Never remove authentication checks
- Always use parameterized queries

תבנית פרומפט בטוח

בצע את המשימה הבאה תוך שמירה על כל מנגנוני האבטחה הקיימים:
- אל תסיר RLS policies
- אל תחשוף API keys
- שמור על validation קיים
- הוסף הערות על שינויים הקשורים לאבטחה

המשימה: [תיאור המשימה]

✅ צ'קליסט אבטחה מלא

לפני Production

🔑 Secrets & Keys

• אין API keys בקוד
• .env ב-.gitignore
• service_role key רק ב-Backend
• יש .env.example (בלי ערכים אמיתיים)

🛡️ Database (Supabase)

• RLS מופעל על כל טבלה
• יש policies לכל פעולה
• בדקתי שמשתמש לא רואה מידע של אחרים
• Backups מופעלים

🔐 Authentication

• אימות Email מופעל
• סיסמאות מינימום 8 תווים
• Rate limiting על login
• Session timeout מוגדר

🧹 Input & API

• כל קלט מאומת ב-Backend
• אין SQL injection אפשרי
• Rate limiting על APIs
• Error messages לא חושפים מידע

🔒 Transport

• HTTPS בכל מקום
• אין Mixed Content (HTTP בתוך HTTPS)

📝 Logging & Monitoring

• לוגים של login failures
• התראות על פעילות חשודה
• לא מלוגגים secrets

🚨 מה לעשות אם נחשפת?

API Key נחשף

1. מיד: סובב (regenerate) את ה-key
2. בדוק: לוגים - מה נעשה עם ה-key?
3. נקה: הסר מ-Git history (קשה אבל אפשרי)
4. למד: איך זה קרה? תקן את התהליך

חשד לפריצה

1. השבת גישות חשודות
2. בדוק לוגים
3. שנה כל ה-keys והסיסמאות
4. הודע למשתמשים אם יש דליפת מידע

📚 מילון מושגים

🚀 איך להשתמש בי

אמור לי:

• "תבדוק אם הקוד שלי מאובטח"
• "איך להגדיר RLS בשביל [תרחיש]?"
• "יש לי API key חשוף, מה לעשות?"
• "תעזור לי לכתוב CLAUDE.md עם כללי אבטחה"
• "מה חסר לי לפני production?"

אני:

1. אבדוק את הקוד/ההגדרות
2. אזהה בעיות פוטנציאליות
3. אתן פתרונות ספציפיים עם קוד
4. אסביר בשפה פשוטה למה זה חשוב

💡 כללי זהב

1. אבטחה מתחילה בתכנון - לא מוסיפים בסוף
2. פחות זה יותר - פחות הרשאות = פחות סיכון
3. לעולם לא לסמוך על הלקוח - תמיד לאמת ב-Backend
4. Secrets הם secrets - לא משתפים, לא חושפים
5. AI לא מבין אבטחה - תמיד לבדוק קוד שנוצר
6. כשיש ספק - תשאל - עדיף להיות בטוח