🔒 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 - חובה!
# 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 - הבדל קריטי!
| Key | מה זה | איפה להשתמש | האם לחשוף? |
|---|---|---|---|
| anon key | מפתח ציבורי | Frontend | ✅ כן (עם RLS!) |
| service_role key | מפתח אדמין | Backend בלבד | ❌ לעולם לא! |
כלל זהב:
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 נפוצות
| תרחיש | 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 |
קוד לדוגמה - בדיקת משתמש מחובר
// 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
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
# ב-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 נחשף
- •מיד: סובב (regenerate) את ה-key
- •בדוק: לוגים - מה נעשה עם ה-key?
- •נקה: הסר מ-Git history (קשה אבל אפשרי)
- •למד: איך זה קרה? תקן את התהליך
חשד לפריצה
- •השבת גישות חשודות
- •בדוק לוגים
- •שנה כל ה-keys והסיסמאות
- •הודע למשתמשים אם יש דליפת מידע
📚 מילון מושגים
| מושג | הסבר פשוט |
|---|---|
| RLS | שליטה מי רואה איזה שורה בטבלה |
| JWT | "כרטיס כניסה" דיגיטלי שמוכיח מי אתה |
| HTTPS | תקשורת מוצפנת באינטרנט |
| API Key | סיסמה שמזהה את האפליקציה שלך |
| Injection | הכנסת קוד זדוני דרך קלט |
| XSS | הכנסת JavaScript זדוני לאתר |
| MFA/2FA | אימות דו-שלבי (סיסמה + קוד) |
| Hashing | הפיכת סיסמה לקוד בלתי הפיך |
| Encryption | הצפנה (אפשר לפענח עם מפתח) |
| Rate Limiting | הגבלת כמות בקשות |
🚀 איך להשתמש בי
אמור לי:
- •"תבדוק אם הקוד שלי מאובטח"
- •"איך להגדיר RLS בשביל [תרחיש]?"
- •"יש לי API key חשוף, מה לעשות?"
- •"תעזור לי לכתוב CLAUDE.md עם כללי אבטחה"
- •"מה חסר לי לפני production?"
אני:
- •אבדוק את הקוד/ההגדרות
- •אזהה בעיות פוטנציאליות
- •אתן פתרונות ספציפיים עם קוד
- •אסביר בשפה פשוטה למה זה חשוב
💡 כללי זהב
- •אבטחה מתחילה בתכנון - לא מוסיפים בסוף
- •פחות זה יותר - פחות הרשאות = פחות סיכון
- •לעולם לא לסמוך על הלקוח - תמיד לאמת ב-Backend
- •Secrets הם secrets - לא משתפים, לא חושפים
- •AI לא מבין אבטחה - תמיד לבדוק קוד שנוצר
- •כשיש ספק - תשאל - עדיף להיות בטוח