שגיאה 403 באתר וורדפרס: למה זה קורה ואיך מתקנים

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

בגלל זה הטיפול שונה מהודעה כמו Error Establishing a Database Connection. לא מחפשים תוסף שנשבר, אלא מי חוסם: חוק בקובץ .htaccess, הרשאות קבצים שגויות, תוסף אבטחה, או חומת האש של השרת או של Cloudflare. סידרתי למטה את הבדיקות לפי הסדר, ובכל אחת כתבתי איך מזהים את הסיבה ואיך מתקנים אותה.

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

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

יש עוד כמה שאלות שעוזרות לצמצם את החיפוש:

• האם השגיאה מופיעה בכל האתר, או רק בכתובת מסוימת כמו /wp-admin או wp-login.php?
• האם היא מופיעה לכולם, או רק לך, מרשת מסוימת או ממכשיר מסוים? חסימה לפי כתובת IP נראית בדיוק כך.
• מה השתנה לאחרונה: תוסף חדש, עדכון, מעבר שרת, שינוי ב-Cloudflare?

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

אם החסימה אצל Cloudflare, אפשר לדלג לשלב 5. אם היא מגיעה מהשרת, ממשיכים לשלב 2.

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

כדי לבדוק אם הקובץ הוא הבעיה:

1. ב-FTP או במנהל הקבצים נכנסים לתיקייה הראשית של האתר ומשנים את שם הקובץ .htaccess ל-.htaccess_old. בהרבה תוכנות FTP קבצים שמתחילים בנקודה מוסתרים, ולפעמים צריך להפעיל הצגה של קבצים מוסתרים.
2. טוענים את האתר. אם השגיאה נעלמה, הבעיה בקובץ.
3. נכנסים ל-Settings > Permalinks ולוחצים על Save Changes, כדי שוורדפרס תיצור קובץ חדש. אם מופיעה ההודעה "You should update your .htaccess now.", מעתיקים ידנית את הכללים שמוצגים בתחתית המסך.
4. אם היו בקובץ הישן חוקים שאתה צריך, מחזירים אותם אחד אחד ובודקים אחרי כל אחד. החוק ששובר את הגישה הוא זה שאחריו השגיאה חוזרת.

אם השגיאה מופיעה רק בנתיב מסוים, כדאי לבדוק גם קבצי .htaccess בתתי-תיקיות, למשל בתוך wp-content או wp-content/uploads.

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

התיעוד של וורדפרס על הרשאות קבצים ממליץ, בשרתים שמריצים את ה-PHP תחת המשתמש שלך (suexec), על ההגדרות האלה:

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

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

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

יש כמה דרכים לבדוק:

• אם יש לך גישה ללוח הבקרה, נכנסים להגדרות התוסף ובודקים את רשימת החסימות. אם הכתובת שלך שם, משחררים אותה.
• אם אין גישה, נכנסים ב-FTP ל-wp-content/plugins ומשנים את שם התיקייה של תוסף האבטחה. וורדפרס תשבית אותו, וההגדרות שלו יישמרו.
• אם לא ברור איזה תוסף אשם, משנים את שם התיקייה plugins ל-plugins.hold, נכנסים ל-/wp-admin/plugins.php, מחזירים את השם ל-plugins, ומפעילים את התוספים אחד אחד.

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

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

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

ב-Cloudflare: לפי התיעוד שלהם, Cloudflare מחזירה 403 כשבקשה הפרה חוק של חומת האש לאפליקציות (WAF), מנוהל או מותאם אישית, וגם בעקבות הגדרות אבטחה נוספות: Security Level (שברירת המחדל שלו היא Medium), הגנת DDoS שפועלת כברירת מחדל, ו-Browser Integrity Check. בלוח הבקרה של Cloudflare, באזור Security Events, אפשר לראות את הבקשות שנחסמו ולזהות איזה חוק חסם. כשמוצאים אותו, משנים את החוק או מוסיפים חריגה מדויקת לכתובת שנחסמה, במקום לכבות את ההגנה כולה.

לפי התיעוד של Google Search Central, גוגל מתייחסת לכל שגיאות 4xx, חוץ מ-429, באותה דרך: היא מסיקה שהתוכן לא קיים. עמוד שמחזיר 403 לסורק של גוגל מטופל אצלה כמו עמוד שלא קיים. ב-Search Console עמודים כאלה מופיעים בדוח ההוספה לאינדקס עם הסיבה Blocked due to access forbidden (403).

גוגל גם מבקשת לא להשתמש ב-401 או ב-403 כדי להגביל את קצב הסריקה, כי קודי 4xx (חוץ מ-429) לא משפיעים עליו. כך שאם חומת האש חוסמת את הסורק של גוגל, היא לא מאטה אותו, אלא פשוט מוציאה עמודים מהאינדקס. הרחבתי על המצב הזה במדריך למה האתר שלי לא מופיע בגוגל.

יש מצבים שבהם כדאי לעצור לפני שממשיכים לבד:

• אין לך גיבוי עדכני, ואתה לא בטוח שתוכל לשחזר את האתר.
• אתה לא בטוח מה ההרשאות הנכונות בשרת שלך, או ששינוי הרשאות ישבור משהו אחר.
• החסימה מגיעה מחומת האש של השרת, ואין לך גישה אליה.
• עמודים חשובים מופיעים ב-Search Console עם הסיבה Blocked due to access forbidden (403) ואתה לא מוצא מי חוסם את גוגל.
• עברת על כל השלבים והשגיאה עדיין מופיעה.

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