אבטחת אתר וורדפרס: שגרה מעשית שמקטינה את הסיכון

מה כוללת אבטחת אתר וורדפרס ומי אחראי עליה?

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

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

איך מנהלים עדכוני וורדפרס בלי לשבור את האתר?

עדכוני וורדפרס הם שכבת ההגנה הבסיסית ביותר, כי הם סוגרים פרצות שכבר התגלו. לפי התיעוד של WordPress.org, עדכונים אוטומטיים ברקע קיימים מאז גרסה 3.7, ובהתקנות חדשות מאז גרסה 5.6 הם פעילים כברירת מחדל גם לגרסאות ראשיות. לתוספים ולתבניות יש מאז גרסה 5.5 אפשרות להפעיל עדכון אוטומטי פריט אחר פריט, אבל היא כבויה עד שמנהל האתר מפעיל אותה. לפי אותו תיעוד, וורדפרס מריץ את העדכונים האלה פעמיים ביום ושולח מייל אחרי כל ניסיון עדכון.

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

יש גם שכבה שמתחת לוורדפרס: גרסת PHP של השרת. לפי טבלת הגרסאות הנתמכות באתר של PHP, כל ענף מקבל שנתיים של תמיכה מלאה ועוד שנתיים של תיקוני אבטחה בלבד, ואחר כך לא מקבל תיקונים כלל. נכון לאוקטובר 2026, ענף 8.2 מקבל תיקוני אבטחה רק עד 31 בדצמבר 2026, ולכן אתר שעדיין רץ עליו צריך תוכנית מעבר לגרסה חדשה יותר, אחרי בדיקת תאימות של התבנית והתוספים.

מה הסיכון בתוספים נטושים ובתבניות פרוצות?

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

תבנית או תוסף פרוצים, שמכונים nulled, הם עותקים של מוצרים בתשלום שמישהו הסיר מהם את בדיקת הרישיון והפיץ באתרים לא רשמיים. הבעיה העיקרית היא אמון: אין דרך פשוטה לדעת מה עוד שונה בקוד, ומי שהסיר את בדיקת הרישיון יכול באותה קלות להוסיף קוד משלו. בנוסף, עותק כזה לא מקבל עדכונים מהיצרן. מדריך ההקשחה של WordPress.org ממליץ במפורש להתקין תוספים ותבניות רק מהמאגר הרשמי או מחברות מוכרות, ולהסיר כל תוסף שלא בשימוש.

איך מגדירים משתמשים, סיסמאות ואימות דו שלבי?

חשבון ניהול שנפרץ עוקף את כל שאר ההגנות, ולכן ניהול המשתמשים הוא חלק מרכזי באבטחה. לפי התיעוד של וורדפרס, אין להשתמש בשם המשתמש admin, ולכל משתמש כדאי סיסמה ארוכה וייחודית שנוצרת ונשמרת במנהל סיסמאות. וורדפרס לא כולל אימות דו שלבי בליבה, ולכן מוסיפים אותו דרך תוסף או ספק זהות, והתיעוד ממליץ להפעיל אותו לכל המנהלים ולכל משתמש עם הרשאות רחבות. אפשרות נוספת שהתיעוד מזכיר היא מפתחות גישה (Passkeys), שמאפשרים התחברות בלי סיסמה ועמידים יותר בפני פישינג.

העיקרון השני הוא הרשאה מינימלית: לצמצם את מספר המנהלים ולתת לכל משתמש את התפקיד המצומצם ביותר שמספיק לעבודה השוטפת. וורדפרס מגיע עם חמישה תפקידים באתר בודד. Administrator מקבל גישה לכל הגדרות האתר, Editor מפרסם ומנהל את כל התכנים כולל של אחרים, Author מפרסם ומנהל רק את התכנים שלו, Contributor כותב בלי לפרסם, ו-Subscriber מנהל רק את הפרופיל שלו. מי שמעלה מאמרים ומעדכן עמודים מסתדר בדרך כלל עם Editor, ולא צריך הרשאת מנהל.

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

איך מגינים על ההתחברות, על XML-RPC ועל קובץ wp-config?

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

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

בקובץ wp-config.php יש כמה הגדרות שכדאי להכיר. השורה define( 'DISALLOW_FILE_EDIT', true ); מבטלת את עורך הקבצים של התבניות והתוספים בלוח הבקרה, כך שמי שהשיג גישת מנהל לא יוכל לערוך קוד PHP ישירות מהדפדפן. מדריך ההקשחה מציין שזה לא ימנע העלאה של קבצים זדוניים, אבל עשוי לעצור חלק מהמתקפות. הגדרה מחמירה יותר, DISALLOW_FILE_MODS, חוסמת גם התקנה ועדכון של תוספים ותבניות מלוח הבקרה, ולכן היא מתאימה רק לאתר שהעדכונים בו נעשים בתהליך פריסה מסודר. ההגדרה FORCE_SSL_ADMIN מחייבת חיבור מוצפן לאזור הניהול, בתנאי שלאתר יש תעודת ssl תקינה.

איך בונים גיבוי אתר שבאמת אפשר לשחזר ממנו?

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

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

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

איזו שגרת אבטחה כדאי לקבוע לאתר וורדפרס?

חומת אש לאפליקציות (WAF) וסריקת נוזקות משלימות את המניעה. לפי מדריך ההקשחה, אפשר לסנן תעבורה בתוך האתר בעזרת תוסף, או לפני שהיא מגיעה לשרת בעזרת שירות פרוקסי הפוך. סינון בקצה חוסך משאבים לשרת, ותוסף שרץ בתוך האתר רואה את מה שקורה בתוכו. גם לסריקות יש שני סוגים: סורקים שרצים בתוך האתר ובודקים קבצים, וסורקים חיצוניים שבודקים את מה שהגולש רואה, והתיעוד של וורדפרס מציין ששילוב של שניהם משפר את הסיכוי לזהות בעיה.

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

מה עושים אם אתר הוורדפרס נפרץ?

סימנים לפריצה יכולים להיות אזהרה של Google בתוצאות החיפוש, השבתה של האתר על ידי חברת האחסון, משתמשים חדשים שאף אחד לא יצר, או שינוי שרואים בעין כשנכנסים לאתר. השאלות הנפוצות של WordPress.org על אתר שנפרץ מציעות קודם כול לשמור על קור רוח ולתעד: מה ראיתם, מתי, ומה השתנה באתר לאחרונה. אחר כך פועלים לפי סדר קבוע, כי ניקוי בלי לסגור את נקודת הכניסה עלול להחזיר את הבעיה.

• סריקה: סורקים את האתר וגם את המחשבים שמהם מתחברים אליו, כי לפעמים פרטי הגישה נגנבו דווקא שם
• חברת האחסון: מעדכנים אותה, כי בשרת משותף הפריצה עשויה להשפיע על יותר מאתר אחד
• עותק של המצב הנגוע: שומרים צילום מצב לפני הניקוי, כדי שיהיה למה להשוות בהמשך
• איפוס גישות: מחליפים סיסמאות לכל המשתמשים, ל-SFTP, ללוח הבקרה של האחסון ולמסד הנתונים, ומחליפים את מפתחות האבטחה ב-wp-config.php כדי לנתק כל מי שמחובר
• ניקוי או שחזור: משחזרים מגיבוי נקי, או מחליפים את התיקיות wp-admin ו-wp-includes בעותק נקי של אותה גרסה דרך SFTP, ובודקים במיוחד את קובץ .htaccess
• עדכון והחלפה חוזרת: אחרי שהאתר נקי מעדכנים הכול ומחליפים את הסיסמאות שוב

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

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