# Security Specialist

> סיוע באבטחת אפליקציות ווב ו-APIs. השתמש כשמבקשים לאבטח פרויקט, לבדוק חולשות, להגדיר הרשאות, לנהל API keys, או להגן על נתונים. מותאם ל-Vibe Coders שעובדים עם Supabase, FastAPI, ו-Claude Code. מסביר מושגי אבטחה בשפה פשוטה עם צ'קליסטים מעשיים.

- Skill: `aibot88/security-specialist` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add aibot88/security-specialist`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aibot88/security-specialist/raw
- Safety review: pending (external: skill-scanner FAIL, skillspector FAIL)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: aibot88 (https://skillmd.com/u/aibot88)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/aibot88/security-specialist

---


# 🔒 Security Specialist Skill

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

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

---

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

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

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

---

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

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

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

| # | סיכון | מה זה? (מטאפורה) | איך מתגוננים |
|---|-------|------------------|--------------|
| 1 | **Broken Access Control** | דלתות פתוחות בבניין | RLS, בדיקת הרשאות |
| 2 | **Cryptographic Failures** | לשלוח מכתב ללא מעטפה | HTTPS, הצפנה |
| 3 | **Injection** | מישהו כותב על הטופס שלך | Validation, Sanitization |
| 4 | **Insecure Design** | בית בלי מנעול | תכנון אבטחה מראש |
| 5 | **Security Misconfiguration** | להשאיר חלון פתוח | הגדרות נכונות |
| 6 | **Vulnerable Components** | חלקים ישנים ושבורים | עדכון תלויות |
| 7 | **Auth Failures** | מנעול חלש | 2FA, סיסמאות חזקות |
| 8 | **Data Integrity Failures** | לסמוך על כולם | אימות מקור |
| 9 | **Logging Failures** | לא לדעת מה קרה | לוגים ומעקב |
| 10 | **SSRF** | לתת למישהו לשלוט בך | הגבלת בקשות |

---

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

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

| טעות | למה זה רע | מה קורה |
|------|----------|---------|
| **Hardcoding** - לשים key בקוד | אם הקוד ב-GitHub, כולם רואים | פריצה, חיובים |
| **לא לסובב keys** | key ישן = יותר זמן לגנוב | חשיפה ממושכת |
| **אותו key לכל סביבה** | dev = staging = production | דליפה אחת = הכל חשוף |
| **לשתף ב-Slack/Email** | הודעות נשמרות | אנשים לא מורשים רואים |

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

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

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

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

# Supabase
supabase/.env
```

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

```bash
# .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 - הבדל קריטי!

| Key | מה זה | איפה להשתמש | האם לחשוף? |
|-----|-------|-------------|-----------|
| **anon key** | מפתח ציבורי | Frontend | ✅ כן (עם RLS!) |
| **service_role key** | מפתח אדמין | Backend בלבד | ❌ לעולם לא! |

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

---

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

### מהו RLS? (Row Level Security)

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

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

### איך זה עובד

```sql
-- שלב 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 נפוצות

| תרחיש | Policy |
|-------|--------|
| **משתמש רואה רק את שלו** | `USING (auth.uid() = user_id)` |
| **כולם רואים, רק בעלים עורך** | `FOR SELECT USING (true)` + `FOR UPDATE USING (auth.uid() = user_id)` |
| **רק משתמשים מחוברים** | `USING (auth.role() = 'authenticated')` |
| **ציבורי לקריאה** | `FOR SELECT USING (is_public = true)` |

### צ'קליסט 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)                         │
└─────────────────────────────────────────────────────────────┘
```

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

| הגדרה | המלצה | למה |
|-------|-------|-----|
| **אימות Email** | ✅ כן | מונע חשבונות מזויפים |
| **Password מינימום** | 8+ תווים | מונע סיסמאות חלשות |
| **MFA** | ✅ כן (לפחות אופציונלי) | שכבת הגנה נוספת |
| **Session timeout** | 1-24 שעות | מגביל זמן חשיפה |
| **Rate limiting** | ✅ כן | מונע Brute Force |

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

```typescript
// 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 (אימות קלט)

### למה זה חשוב?

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

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

| התקפה | מה זה | דוגמה |
|--------|-------|-------|
| **SQL Injection** | הכנסת פקודות SQL | `'; DROP TABLE users; --` |
| **XSS** | הכנסת JavaScript | `<script>alert('hacked')</script>` |
| **Command Injection** | הכנסת פקודות מערכת | `; rm -rf /` |

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

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

### קוד לדוגמה - FastAPI

```python
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 - חובה!

| ללא 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 עלול לעשות |
|-----------|------------------|
| "תגרום לזה לעבוד" | להסיר RLS policies |
| "תפשט את הקוד" | להוריד validation |
| "תן לי לראות את כל הנתונים" | לפתוח הכל לציבור |

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

```markdown
# ב-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** | שליטה מי רואה איזה שורה בטבלה |
| **JWT** | "כרטיס כניסה" דיגיטלי שמוכיח מי אתה |
| **HTTPS** | תקשורת מוצפנת באינטרנט |
| **API Key** | סיסמה שמזהה את האפליקציה שלך |
| **Injection** | הכנסת קוד זדוני דרך קלט |
| **XSS** | הכנסת JavaScript זדוני לאתר |
| **MFA/2FA** | אימות דו-שלבי (סיסמה + קוד) |
| **Hashing** | הפיכת סיסמה לקוד בלתי הפיך |
| **Encryption** | הצפנה (אפשר לפענח עם מפתח) |
| **Rate Limiting** | הגבלת כמות בקשות |

---

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

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

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

---

## 💡 כללי זהב

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