AgentSkillsCN

security-specialist

协助保护 Web 应用与 API 安全。当有人希望为项目加固安全防线、检测潜在漏洞、设置权限控制、管理 API 密钥,或保护敏感数据时,可使用此技能。尤其适用于与 Supabase、FastAPI、Claude Code 深度协作的 Vibe Coders。以通俗易懂的语言讲解安全概念,并结合实用的案例与技巧。

SKILL.md
--- frontmatter
name: security-specialist
description: |
  סיוע באבטחת אפליקציות ווב ו-APIs. השתמש כשמבקשים לאבטח פרויקט,
  לבדוק חולשות, להגדיר הרשאות, לנהל API keys, או להגן על נתונים.
  מותאם ל-Vibe Coders שעובדים עם Supabase, FastAPI, ו-Claude Code.
  מסביר מושגי אבטחה בשפה פשוטה עם צ'קליסטים מעשיים.

🔒 Security Specialist Skill

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

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


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

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

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

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

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

מהו OWASP?

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

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

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

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

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

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

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

code
┌─────────────────────────────────────────────────────────────┐
│                    איפה לשמור 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 נותן לך

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

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

הגדרההמלצהלמה
אימות Email✅ כןמונע חשבונות מזויפים
Password מינימום8+ תוויםמונע סיסמאות חלשות
MFA✅ כן (לפחות אופציונלי)שכבת הגנה נוספת
Session timeout1-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 /

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

code
✅ תמיד לאמת בצד השרת (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)

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

code
┌─────────────────────────────────────────────────────────────┐
│           מה להצפין?                                        │
├─────────────────────────────────────────────────────────────┤
│  ✅ סיסמאות (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

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

code
בצע את המשימה הבאה תוך שמירה על כל מנגנוני האבטחה הקיימים:
- אל תסיר 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. כשיש ספק - תשאל - עדיף להיות בטוח