בדיקות אבטחת אתר שאפשר להריץ בלי לפרוץ לשום דבר

בדיקות אבטחת אתר פסיביות לחנויות אונליין: תוקף תעודת TLS/SSL, HSTS, CSP, nosniff, דגלי עוגיות, תוכן מעורב, jQuery מיושן, security.txt ו-DMARC.

צוות התוכן של FixReportsזמן קריאה: 9 דק׳

אפשר לבדוק חלק גדול מהגדרות האבטחה של חנות אונליין מבחוץ, פשוט על ידי קריאת מה שהאתר כבר שולח לכל מבקר: תעודת ה-TLS שלו, ההפניות, כותרות התגובה של HTTP, העוגיות, הסקריפטים שהוא טוען ורשומות ה-DNS הציבוריות שלו. הבדיקות הפסיביות האלה לא שולחות תעבורת תקיפה ולא דורשות התחברות, ולכן הן לא מעמיסות על החנות יותר מביקור רגיל. הן מאתרות פערי תצורה כמו תעודה שעומדת לפוג, HSTS חסר, עוגיות לא מאובטחות, תוכן מעורב או גרסת jQuery עם פגיעויות ידועות. הן אינן מבדק חדירות ואינן יכולות להוכיח שחנות מאובטחת.

עיקרי הדברים

מה נחשב לבדיקת אבטחה פסיבית?

בדיקה פסיבית רק קוראת את מה שהאתר או ה-DNS שלו מחזירים לבקשה רגילה.

כלומר: טעינה של דפים ציבוריים, קריאה של התעודה ושל כותרות התגובה, רישום של העוגיות והסקריפטים שדף מגדיר, ושאילתות על רשומות DNS ציבוריות. בדיקה פסיבית לא מנחשת סיסמאות, לא שולחת מטעני הזרקה (injection payloads), לא מגששת אחרי כתובות של ממשק הניהול ולא סורקת פורטים. את כל מה שמופיע בהמשך אפשר לעשות עם דפדפן, curl, openssl ו-dig.

איך בודקים את תעודת ה-TLS ואת תאריך התפוגה שלה?

קראו ישירות את התאריכים והשמות שבתעודה, וודאו שהחידוש שלה אוטומטי.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

ודאו ש-notAfter רחוק מספיק בעתיד, שהתעודה מכסה גם את example.com וגם את www.example.com אם אתם משתמשים בשניהם (מציג התעודות של הדפדפן מפרט את השמות), ושהדפדפן לא מציג אזהרות. משך התוקף של תעודות הולך ומתקצר לפי ה-Baseline Requirements של ה-CA/Browser Forum (סעיף 6.3.2, גרסה 2.3.1 נכון לאוקטובר 2026), בעקבות Ballot SC-081v3 (נפתח בכרטיסייה חדשה), שאומץ ב-11 באפריל 2025:

מועד הנפקת התעודהתוקף מרבי
לפני 15 במרץ 2026398 יום
15 במרץ 2026 עד 14 במרץ 2027200 יום
15 במרץ 2027 עד 14 במרץ 2029100 יום
מ-15 במרץ 202947 יום

תוקף קצר הופך חידוש ידני למסוכן, ולכן ודאו שחברת האחסון או כלי התעודות שלכם מחדשים את התעודה אוטומטית. ודאו גם ש-HTTP רגיל מפנה ל-HTTPS:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

התשובה הרצויה היא 301 (או 308) עם כותרת location שמתחילה ב-https://.

אילו כותרות אבטחה חנות אונליין צריכה לשלוח?

קבוצה קטנה של כותרות תגובה חוסמת התקפות נפוצות בצד הדפדפן, כמעט בלי עלות.

כותרתמה היא עושהערך טיפוסימקור
Strict-Transport-Securityאומרת לדפדפנים להשתמש רק ב-HTTPS ומונעת ממשתמשים לעקוף שגיאות תעודה בלחיצהmax-age=31536000; includeSubDomainsMDN (נפתח בכרטיסייה חדשה)
Content-Security-Policy: frame-ancestorsקובעת אילו אתרים רשאים להטמיע את הדפים שלכם, וכך מגינה מפני clickjackingframe-ancestors 'self'MDN (נפתח בכרטיסייה חדשה)
X-Frame-Optionsבקרת מסגור (framing) ותיקה יותר; לפי OWASP, frame-ancestors מייתרת אותה בדפדפנים שתומכים בהDENY או SAMEORIGINOWASP (נפתח בכרטיסייה חדשה)
X-Content-Type-Optionsעוצרת MIME sniffing וחוסמת סקריפטים וגיליונות סגנון שמוגשים עם סוג שגויnosniffMDN (נפתח בכרטיסייה חדשה)
Referrer-Policyמגבילה כמה מהכתובות שלכם נשלח לאתרים אחריםstrict-origin-when-cross-originOWASP
X-XSS-Protectionכותרת של מסנן XSS בדפדפן; לפי OWASP, היא עלולה ליצור פגיעויות XSS באתרים שהיו בטוחים בלעדיהלא להגדיר, או 0OWASP

בדקו מה החנות שלכם שולחת:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

שתי אזהרות. includeSubDomains חוסם כל תת-דומיין שעובד רק ב-HTTP, ולכן בדקו קודם את תתי-הדומיינים. רישום מראש של HSTS (preload) מחייב max-age של 31536000 לפחות ואת includeSubDomains, ולכן הוסיפו preload רק כשכל תתי-הדומיינים מוכנים ל-HTTPS. מדיניות CSP מלאה שמגבילה סקריפטים שווה את ההשקעה, אבל OWASP מציין שהיא מורכבת להגדרה ולתחזוקה, וחנויות עם הרבה אפליקציות צריכות לבדוק אותה בקפידה.

האם העוגיות שלכם מוגדרות עם Secure, HttpOnly ו-SameSite?

עוגיות של סשן ושל סל צריכות לשאת את שלושת המאפיינים, ואפשר לראות אותם בכותרות התגובה Set-Cookie.

מאפייןההשפעה (לפי MDN (נפתח בכרטיסייה חדשה))איפה זה חשוב
Secureהעוגייה נשלחת רק ב-HTTPS; אתרים ב-HTTP רגיל לא יכולים להגדיר אותוכל עוגייה בחנות שפועלת ב-HTTPS
HttpOnlyJavaScript לא יכול לקרוא את העוגייה דרך document.cookie, וזה עוזר נגד XSSסשנים של התחברות וסלים
SameSite=Lax או Strictמגביל מתי העוגייה נשלחת בבקשות בין אתרים (cross-site)סשנים; Strict מתאים לעוגיות אימות ולעוגיות סל
SameSite=Noneהעוגייה נשלחת בבקשות בין אתרים; חובה לשלב אותו עם Secureרק תכונות מוטמעות של צד שלישי שזקוקות לכך

אם לא הוגדר מאפיין SameSite, דפדפנים מתייחסים לעוגייה כאל Lax. עוגיות שהסקריפטים שלכם צריכים לקרוא לא יכולות להיות HttpOnly, ולכן התמקדו בעוגיות שמזהות לקוח מחובר או מנהל.

curl -sI https://example.com/ | grep -i "^set-cookie"

כלי הפיתוח של הדפדפן מציגים את אותו מידע, כולל עוגיות שסקריפטים מגדירים אחרי שהדף נטען.

איך מוצאים תוכן מעורב (mixed content)?

תוכן מעורב הוא כל משאב שנטען ב-HTTP בדף שמוגש ב-HTTPS, וקונסולת הדפדפן מפרטת אותו.

MDN (נפתח בכרטיסייה חדשה) מחלק אותו לשתי קבוצות. תמונות, אודיו ווידאו הם "ניתנים לשדרוג" (upgradable): דפדפנים מבקשים אותם אוטומטית ב-HTTPS. סקריפטים, גיליונות סגנון, iframes, גופנים ובקשות fetch() הם "ניתנים לחסימה" (blockable): דפדפנים חוסמים אותם, וזה שובר את כל מה שהיה תלוי בהם. גם בקשות משודרגות לכתובת IP חשופה נחסמות.

כדי למצוא אותו, פתחו את הקונסולה בתבניות המרכזיות (דף בית, דף קטגוריה, דף מוצר, סל) וחפשו http:// בקוד התבנית, בתוכן הדפים ובהגדרות האפליקציות. מרכז העזרה של Shopify מציין שכל דף בחנות שיש בו משאב שלא מועבר ב-HTTPS נחשב לא מאובטח (נפתח בכרטיסייה חדשה), וממליץ לארח משאבים ב-Shopify או להגיש אותם ב-HTTPS. ב-WooCommerce, אם האתר פעל אי פעם ב-http://, בדקו תוכן ישן של פוסטים ואת האפשרויות של התבנית.

איך מזהים ספריות JavaScript מיושנות עם CVE ידועים?

רשמו את הספריות שכל דף טוען, קראו את הגרסאות שלהן והשוו אותן למאגר הפגיעויות הלאומי של ארה״ב (NVD).

התחילו ב-jQuery. בקונסולת הדפדפן, $.fn.jquery מחזיר את הגרסה שנטענה (jQuery API (נפתח בכרטיסייה חדשה)). גרסאות שכדאי לסמן:

CVEגרסאות מושפעותהבעיהציון NVD (v3.1)
CVE-2020-11022 (נפתח בכרטיסייה חדשה)מ-1.12.0 ועד לפני 3.5.0העברת HTML לא מהימן למתודות כמו .html() או .append() עלולה להריץ קוד6.1 Medium
CVE-2020-11023 (נפתח בכרטיסייה חדשה)מ-1.0.3 ועד לפני 3.5.0אותו דבר, עבור HTML שמכיל רכיבי <option>; בקטלוג ה-KEV של CISA מאז 23 בינואר 20256.1 Medium
CVE-2019-11358 (נפתח בכרטיסייה חדשה)לפני 3.4.0זיהום אב-טיפוס (prototype pollution) דרך jQuery.extend(true, ...)6.1 Medium

שתי הבעיות מ-2020 תוקנו ב-jQuery 3.5.0. גרסה פגיעה פירושה שהקוד הפגום נמצא באתר; האם אפשר לנצל אותו תלוי באופן שבו האתר מעביר אליו נתונים. WordPress כוללת את jQuery 3.5.1 מאז גרסה 5.6 (נפתח בכרטיסייה חדשה), ולכן jQuery ישן בחנות WooCommerce מצביע על WordPress שלא עודכנה, או על תבנית או תוסף שטוענים עותק משלהם. ב-Shopify, בדקו את קובצי התבנית ואת האפליקציות שמזריקות סקריפטים.

מהו security.txt והאם החנות שלכם צריכה אותו?

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

RFC 9116 (נפתח בכרטיסייה חדשה) (אפריל 2022, RFC מסוג Informational, כך שהעמידה בו וולונטרית) קובע שהקובץ חייב להיות מוגש ב-HTTPS בנתיב /.well-known/security.txt כ-text/plain. השדות Contact ו-Expires הם חובה, וה-RFC ממליץ על תאריך Expires שרחוק פחות משנה קדימה.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

ב-WooCommerce אפשר להציב את הקובץ בשרת. בפלטפורמה מתארחת, בדקו אם אפשר לפרסם קובץ בנתיב הזה; אם לא, פרטי קשר לענייני אבטחה שמסומנים בבירור בדף יצירת הקשר עדיין עוזרים.

איך DMARC מגן על החנות מפני זיוף דוא״ל?

DMARC מאפשר לבקש מספקי תיבות דואר להעביר להסגר או לדחות דואר שמשתמש בדומיין שלכם בכתובת ה-From בלי לעבור SPF או DKIM מיושרים.

רשומה עם p=none רק אוספת דוחות; היא לא עוצרת דואר מזויף. לקוחות מצפים לקבל אישורי הזמנה ואיפוסי סיסמה מהדומיין שלכם, ולכן כדאי לחסום הודעת פישינג שמציגה בדיוק את הדומיין שלכם. בדקו את המדיניות עם dig +short TXT _dmarc.example.com, ועיינו ב-RFC 9989 (נפתח בכרטיסייה חדשה) לקבלת המפרט. DMARC לא מכסה דומיינים דומים (lookalike), אלא רק את הדומיין שמפרסם את הרשומה.

במה Shopify מטפלת, ומה בשליטתכם ב-WooCommerce?

Shopify מפעילה את השרתים שמאחורי חזיתות החנויות שלה, ואילו בחנות WooCommerce באחסון עצמי הגדרות השרת נשארות בידיכם ובידי חברת האחסון.

בדיקהShopifyWooCommerce (אחסון עצמי)
תעודת TLSחינם לכל הדומיינים שנוספו ל-Shopify (נפתח בכרטיסייה חדשה); בדומיינים של צד שלישי זה עשוי לקחת עד 48 שעותחברת האחסון או הגדרה עצמית שלכם
הפניה מ-HTTP ל-HTTPSהפלטפורמההגדרות שרת האינטרנט, ה-CDN או חברת האחסון
כותרות אבטחהנשלחות מהשרתים של Shopifyשרת האינטרנט, ה-CDN או תוסף
דגלי עוגיותהעוגיות של Shopify עצמה מוגדרות על ידי הפלטפורמה; עוגיות של אפליקציות ושל התבנית באחריותכםליבת WordPress, התוספים והשרת
תוכן מעורב וספריות JSהתבנית, התוכן והאפליקציות שלכםהתבנית, התוכן והתוספים שלכם
security.txt ו-DMARCהדומיין וה-DNS שלכםהדומיין וה-DNS שלכם

כשבדקנו כמה חזיתות חנות שמתארחות ב-Shopify באוקטובר 2026, התגובות שלהן כללו HSTS עם max-age של כ-91 יום, X-Content-Type-Options: nosniff ו-CSP עם upgrade-insecure-requests, ואילו frame-ancestors השתנה מחנות לחנות. Shopify מצהירה שהיא מוסמכת כעומדת ב-PCI DSS ברמה 1 (נפתח בכרטיסייה חדשה). התבנית והאפליקציות שהתקנתם נשארות באחריותכם.

ב-WooCommerce, מדריך ההקשחה (נפתח בכרטיסייה חדשה) של WordPress ממליץ לעדכן את WordPress ואת התוספים, למחוק תוספים שאינכם משתמשים בהם, ולשאול את חברת האחסון אילו אמצעי אבטחה היא נוקטת.

למה זה לא מבדק חדירות?

מבדק חדירות מנסה לבצע התקפות באופן אקטיבי; בדיקות פסיביות רק מתבוננות.

NIST SP 800-115 מגדיר מבדק חדירות כבדיקת אבטחה שבה הבודקים מחקים התקפות מהעולם האמיתי כדי למצוא דרכים לעקוף את מנגנוני האבטחה של מערכת (מילון המונחים של NIST (נפתח בכרטיסייה חדשה)). בדיקות פסיביות לא יכולות לראות פגמים בצד השרת בתוספים, סיסמאות ניהול חלשות או ממוחזרות, היעדר אימות דו-שלבי, בקרת גישה פגומה או קוד פגיע שאף פעם לא מופיע בקוד המקור של הדף. השתמשו בהן כבסיס שאפשר לחזור עליו בכל עת. לביטחון מעמיק יותר, הזמינו מבדק חדירות עם היקף מוגדר בכתב, על מערכות שבבעלותכם או שאתם מורשים לבדוק.

הסריקה החינמית מריצה מעבר ראשון על החנות שלכם. דוח אבטחת אתר מכסה את הבדיקות הפסיביות שבמאמר הזה, מ-TLS והפניות ועד כותרות, עוגיות, תוכן מעורב, ספריות מיושנות, security.txt ו-DMARC, עם תיקון לכל ממצא. כמו כל סקירה פסיבית, הוא לא יכול להבטיח שחנות מאובטחת.

שאלות נפוצות

האם בדיקות אבטחה פסיביות מסכנות את החנות שלי?

לא יותר מביקור רגיל. הן מבקשות את אותם דפים ציבוריים ורשומות DNS שכל דפדפן או שרת דואר היה מבקש, והן לא מנסות להתחבר או לשלוח מטעני תקיפה.

האם אפשר להוסיף כותרות אבטחה ב-Shopify?

כותרות התגובה של חזית החנות מגיעות מהשרתים של Shopify, ולכן אם חסרה כותרת שאתם צריכים, פנו לתמיכה של Shopify. תג <meta> של CSP בתבנית יכול להוסיף חלק מההנחיות, אבל MDN מציין ש-frame-ancestors לא נתמך ב-<meta>.

האם גרסת jQuery ישנה אומרת שהחנות שלי נפרצה?

לא. היא אומרת שנטען קוד עם פגיעויות ידועות, וזה מעלה את הסיכון אם האתר מעביר HTML לא מהימן למתודות המושפעות. עדכנו את הספרייה, או הסירו את התבנית או התוסף שטוענים אותה.

כמה זמן תעודת TLS יכולה להיות בתוקף היום?

תעודות מהימנות לציבור שהונפקו מ-15 במרץ 2026 יכולות להיות בתוקף 200 יום לכל היותר. המגבלה יורדת ל-100 יום מ-15 במרץ 2027 ול-47 יום מ-15 במרץ 2029.

האם קובץ security.txt הוא חובה?

RFC 9116 הוא RFC מסוג Informational, ולכן פרסום הקובץ הוא וולונטרי לפי התקן. הפרסום שלו זול, והוא נותן לחוקרים דרך ברורה ליצור איתכם קשר.

האם סריקה פסיבית נקייה אומרת שהחנות שלי מאובטחת?

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

מקורות

כל המדריכים