הקובץ wp-config.php הוא הסוד הכי גדול באתר WordPress. הוא מכיל את סיסמת ה-DB, את שם בסיס הנתונים, ואת שמונת המפתחות הסודיים שמצפינים cookies של התחברות. אם הקובץ נחשף, מי שיקרא אותו יכול להתחבר ישירות לבסיס הנתונים, לזייף sessions של מנהלים, ולגנוב את כל המידע באתר. ההרשאות של הקובץ הן ההגנה הראשונה.
למה זה משנה
בשרת shared hosting, מאות לקוחות חולקים את אותו hardware. אם wp-config.php מוגדר עם הרשאות 644 (-rw-r--r--), כל לקוח אחר על אותו שרת יכול לקרוא אותו דרך שגיאת LFI בפלאגין שלו, או דרך תהליך PHP פשוט שמבצע file_get_contents. גם בשרת ייעודי, סקריפט PHP פגיע בתוסף אחד יכול לקרוא קבצי הגדרות של תוסף אחר אם ההרשאות פתוחות. הרשאה 777 (-rwxrwxrwx) היא קטסטרופה: כל אחד יכול גם לכתוב לקובץ ולשנות את הסיסמה ל-DB. הרשאה תקינה היא 600 (-rw-------) - רק הבעלים של הקובץ קורא וכותב, אף אחד אחר לא רואה כלום. במקרים שבהם PHP-FPM רץ כיוזר אחר ממה שמחזיק את הקבצים, 640 (-rw-r-----) עם group של www-data היא הפתרון.
איך לזהות
דרך SSH הרץ ls -la wp-config.php. הפלט מתחיל ב-מאפיין ההרשאות. -rw------- = 600 (תקין). -rw-r--r-- = 644 (פגיע על shared). -rwxrwxrwx = 777 (קטסטרופה). הבדיקה האוטומטית של RankPlus מבצעת stat() על הקובץ ובודקת את ה-mode. ידנית דרך FTP/SFTP: לחץ קליק ימני על wp-config.php > File Permissions / Properties - אמור להציג 600 או 640.
איך לתקן
- גבה את הקובץ לפני שאתה משנה משהו.
- דרך SSH:
cd /path/to/wordpress chmod 600 wp-config.php ls -la wp-config.php - אם אחרי השינוי האתר מחזיר white screen או 500 - PHP-FPM רץ כיוזר אחר ולא מצליח לקרוא. נסה 640:
chmod 640 wp-config.php chgrp www-data wp-config.php - שם הקבוצה משתנה לפי השרת: www-data ב-Ubuntu/Debian, apache ב-CentOS, nobody בחלק מספקי האחסון. בדוק עם 'ps -ef | grep php-fpm' מי הרץ של הקובץ.
- דרך FTP/SFTP (אם אין SSH): קליק ימני > Properties > הזן 600 בשדה Numeric value, וודא שאינך מסמן 'Recurse into subdirectories'.
- בצע את אותה הקשחה גם על קבצים רגישים נוספים: .htaccess (644), wp-config-sample.php (אפשר למחוק לחלוטין), debug.log (640).
- בדוק שגישת HTTP חסומה: גש ל-https://example.com/wp-config.php בדפדפן. אמור לחזור 403, לעולם לא תוכן הקובץ.
טעויות נפוצות
אל תשתמש ב-FileZilla עם 'Recurse into subdirectories' ו-chmod 600 על שורש האתר - תכבה הרשאות ביצוע על תיקיות ותשבור את האתר. אל תגדיר 444 או 400 - אם תרצה לערוך את הקובץ אתה לא תוכל בלי chmod זמני. אל תניח שספק האחסון 'דואג לזה' - בדוק. אל תחתוף את הבעיה על ידי לקרוא לחברה ולומר 'תעשו לי 777' - זה הופך את הבעיה לחמורה פי כמה.
בדיקה לאחר תיקון
הרץ ls -la wp-config.php - הפלט אמור להתחיל ב--rw------- או -rw-r-----. הרץ שוב את האודיט. נסה לגשת ל-https://example.com/wp-config.php בדפדפן - 403 או דף ריק. בדוק שהאתר פועל תקין ב-5-10 דפים אחרים.
שיקולים נוספים
בסביבות Docker או בקונטיינרים, ההרשאות נקבעות לעיתים בדמותה של ה-image הבסיסית ולא ידנית - ודא ש-Dockerfile או ה-entrypoint שלך מבצע chmod 600 על wp-config.php אחרי כתיבתו. בסביבות עם Kubernetes שמטעינות wp-config.php מ-Secret, ה-mode של הקובץ נקבע ב-defaultMode של ה-volume - הגדר 0600. אם אתה משתמש ב-CI/CD שכותב את wp-config.php אוטומטית, הוסף שורת chmod בשלב deploy לפני שה-traffic מגיע.
קישורים לבדיקות קשורות
- קבצים רגישים חשופים - בודק אם wp-config.bak או .env נגישים מ-HTTP.
- דפדוף תיקיית uploads - מונע directory listing שיכול להוביל לקריאת קבצי הגדרות.
- שלמות קבצי הליבה - מתריע אם wp-config.php או קובץ אחר שונה.