הגברת אבטחת האתר עם קובץ .htaccess

קובץ .htaccess הוא אמצעי אבטחה מעשי שנועד להגן על תיקיות בשרתים מבוססי Apache או LiteSpeed באמצעות שם משתמש וסיסמה, למנוע גישה לקובץ .htaccess עצמו, לאכוף HTTPS ולצמצם גישות מזיקות. השימוש הנפוץ ביותר הוא הגנה על גישה לתיקיות באמצעות Basic Auth ושמירת הסיסמאות בקובץ .htpasswd. עם זאת, חשוב להבין: Basic Auth לבדו אינו מצפין נתונים; לשימוש בטוח יש לעבוד תמיד עם תעודת SSL על גבי HTTPS. תעודת SSL אחסון אתרים מאובטח

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

במדריך זה נעסוק בתהליך ההגנה באמצעות קובץ .htaccess צעד אחר צעד, נסביר את הפקודות הנפוצות ביותר בשימוש במציאות ונשתף דוגמאות שתוכלו להעתיק ולהתאים. הפקודות המפורטות מתאימות במיוחד לסביבות אחסון התומכות ב- Apache mod_rewrite, mod_auth_basic ו-mod_headers. שרתי LiteSpeed תואמים ברובם ל- Apache ולכן רוב הכללים עובדים באותו אופן. עם זאת, לפני שתבצעו שינויים באתר החי, מומלץ לגבות את הקובץ ואם אפשר, לבצע ניסויים על תת-דומיין. ניהול דומיינים גיבוי אתר

מהו קובץ .htaccess ולמה הוא חשוב לאבטחה?

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

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

היתרונות הבולטים של קובץ .htaccess באבטחה הם:

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

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

עקרון ההגנה של קובץ .htaccess: Basic Auth ו-.htpasswd

המונח "הגנה באמצעות קובץ .htaccess" מתייחס בדרך כלל לשני מובנים שונים. הראשון הוא דרישה לשם משתמש וסיסמה בעת כניסה לתיקיה; השני הוא מניעת צפייה בקובץ .htaccess עצמו. הפעולה הראשונה מתבצעת באמצעות Basic Auth, והשנייה באמצעות כללים להגבלת גישה לקובץ.

במבנה Basic Auth, קובץ .htaccess כולל את כלל האימות, בעוד קובץ .htpasswd מכיל את שם המשתמש ואת הסיסמאות המוצפנות. הסיסמאות לא צריכות להישמר בטקסט רגיל. במערכות מודרניות משתמשים בשיטות hash כמו bcrypt, Apache MD5 או SHA. הגישה הבטוחה ביותר היא להשתמש בתכונת פרטיות התיקיה או הגנה באמצעות סיסמה בממשק הניהול של האחסון שלכם; שכן לרוב, ממשקים אלו מציבים את קובץ .htpasswd במיקום הנכון ומבצעים אוטומטית את תהליך ההצפנה.

כלל ההגנה לדוגמה נראה כך:

AuthType Basic

AuthName אזור מוגן

AuthUserFile /home/משתמש/.htpasswd

Require valid-user

המשמעות של ארבע השורות הללו היא פשוטה: סוג האימות מוגדר כ-Basic, שם האזור המוצג בדפדפן מוגדר, מצוין הנתיב המלא של קובץ .htpasswd שבו נמצאות הסיסמאות, ורק למשתמשים חוקיים מותרת הגישה. אחת הטעויות הנפוצות היא לכתוב URL בשורת AuthUserFile. הערך הנכון הוא לא כתובת אינטרנט אלא הנתיב הפיזי של הקובץ בשרת. לדוגמה, https://siteadi.com/.htpasswd הוא שגוי; /home/משתמש/.htpasswd הוא הנכון.

איפה יש לשמור את קובץ .htpasswd?

כדאי לשמור את קובץ .htpasswd מחוץ לתיקיית public_html במידת האפשר. כך, גם אם יש בעיה בהגדרות השרת, הקובץ לא יהיה נגיש ישירות מהאינטרנט. לדוגמה, אם האתר שלכם פועל בתוך /home/שםמשתמש/public_html, עדיף למקם את קובץ .htpasswd ב-/home/שםמשתמש/.htpasswd.

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

הגנה על תיקיות עם .htaccess צעד אחר צעד

השלבים הבאים מתאימים במיוחד למשתמשים המעוניינים להגן על תיקיות כמו admin, panel, test, staging, report או תיקיות מותאמות אישית. לפני תחילת התהליך, גבו את קובץ .htaccess הקיים. אפילו תו שגוי עשוי לגרום לשגיאת 500 Internal Server Error.

1. קביעת התיקיה המוגנת

ראשית, ברור איזו תיקיה אתם מעוניינים להגן עליה. אם לדוגמה אתם רוצים להגן על siteadi.com/admin, תוכלו למקם את קובץ .htaccess בתוך תיקיית admin. אם ברצונכם לסגור את כל האתר באופן זמני ולאפשר גישה רק למורשים, תוכלו להוסיף את הכלל לקובץ .htaccess בתיקיית השורש.

2. יצירת משתמש .htpasswd

אם בממשק הניהול של האחסון שלכם יש כלי להגנה באמצעות סיסמה לתיקיות, זו השיטה הנוחה ביותר. אם לא, ניתן ליצור משתמש בשרתים עם גישה ל-SSH באמצעות פקודת htpasswd. ההיגיון לדוגמה יהיה כך: htpasswd -c /home/משתמש/.htpasswd admin. פקודה זו יוצרת סיסמה עבור המשתמש admin ושומרת אותה בקובץ. כאשר מוסיפים משתמש חדש לקובץ קיים, אין להשתמש בפרמטר -c; אחרת הקובץ עשוי להיווצר מחדש.

3. הוספת כלל .htaccess

הוסיפו את השורות הבאות לקובץ .htaccess בתיקיה המוגנת:

AuthType Basic

AuthName לוח ניהול

AuthUserFile /home/משתמש/.htpasswd

Require valid-user

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

4. אל תשתמשו ללא HTTPS

המידע של Basic Auth מועבר ב-Bas64; זו אינה הצפנה חזקה באמת. אם התנועה מתבצעת דרך HTTP, מישהו המאזין לרשת יכול לתפוס את שם המשתמש והסיסמה. לכן, כלל ההגנה של קובץ .htaccess צריך תמיד להתבצע יחד עם חובת HTTPS. ניתן לצמצם את הסיכון הזה על ידי הפעלת SSL ב-Hostragons ולאחר מכן הוספת כלל הפניית HTTPS. התקנת SSL הפניית HTTPS

חובת HTTPS והפניית www

אחת הצעדים הבסיסיים להגדלת אבטחת האתר היא להפנות את כל התנועה ל-HTTPS. לאחר שהתקנתם תעודת SSL, אפשר להוסיף את הכלל הבא לקובץ .htaccess בתיקיית השורש:

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

כלל זה מעביר בקשות המגיעות ב-HTTP לאותו שם דומיין ואותו נתיב ב-HTTPS. ההפניה הקבועה, המיוצגת על ידי 301, גם מספקת אות נכון מבחינת SEO. אבל אם יש לכם אתר הפועל תחת פרוקסי הפוך, CDN או מאזן עומסים, מצב ה-HTTPS עשוי להיקרא מכותרות שונות. במקרים כאלה יש להשתמש בכלל ההפניה המומלץ על ידי ספק האחסון שלכם.

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

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.ornekdomain\.com$ [NC]

RewriteRule ^(.*)$ https://ornekdomain.com/$1 [L,R=301]

כאן יש לשנות את ornekdomain.com לשם הדומיין שלכם. כאשר אתם מבצעים גם הפניית HTTPS וגם הפניית www, שימו לב לא ליצור הפניות שרשרת. המבנה האידיאלי מביא את המשתמש לכתובת הסופית בצעד אחד. הפניית דומיינים הפניית SEO

פקודות בסיסיות להגברת אבטחת האתר עם .htaccess

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

סגירת רישום תיקיות

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

Options -Indexes

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

מניעת גישה לקבצים רגישים עם .htaccess

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

<Files .htaccess>

Require all denied

</Files>

באופן דומה, קבצים כמו .env, composer.json, composer.lock, config.php.bak, backup.sql, database.sql צריכים להיות חסומים לגישה חיצונית. במיוחד ב-Laravel, Symfony או אפליקציות PHP מותאמות, קובץ .env עשוי להכיל סיסמאות של מסדי נתונים, מפתחות API ומידע SMTP. דליפה של קובץ זה יכולה להוביל להשתלטות על כל המערכת.

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

<FilesMatch ^(\.env|composer\.(json|lock)|package\.json|yarn\.lock|.*\.sql|.*\.bak)$>

Require all denied

</FilesMatch>

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

חסימת PHP בתיקיות מסוימות

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

ניתן להניח קובץ .htaccess בתיקיית העלאה וליישם את ההיגיון הבא:

<FilesMatch \.php$>

Require all denied

</FilesMatch>

כלל זה חוסם גישה לקבצי PHP בתיקיה הרלוונטית. עבור WordPress, הגישה הזו נפוצה בשימוש בתיקיית wp-content/uploads; אולם יש לבדוק זאת, כי ייתכן שיש תוספים שזקוקים לעיבוד קבצים מיוחדים.

הפניית הוטלינק להפחתת צריכת תנועה

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

RewriteEngine On

RewriteCond %{HTTP_REFERER} !^$

RewriteCond %{HTTP_REFERER} !^https?://(www\.)?ornekdomain\.com [NC]

RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC]

כלל זה חוסם בקשות לתמונות המגיעות עם referer שאינו ריק ואינו מהדומיין שלכם. עם זאת, אם יש לכם Google Images, תצוגות רשתות חברתיות, דומיינים של CDN או שותפים, עשוי להיות צורך להוסיף את הדומיינים הללו לרשימת ה-white list. שימוש ב-CDN ביצועי האתר

הענקת גישה או חסימה לכתובות IP מסוימות

אם אתם רוצים לגשת לפאנל הניהול רק מכתובת IP של המשרד שלכם, הגבלת IP היא שכבת הגנה יעילה. עבור Apache 2.4 ומעלה, ההיגיון הבסיסי הוא כך:

Require ip 203.0.113.10

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

כדי לחסום כתובת IP זדונית מסוימת, ניתן להשתמש בהיגיון הבא:

<RequireAll>

Require all granted

Require not ip 198.51.100.25

</RequireAll>

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

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

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

Header always set X-Content-Type-Options nosniff

Header always set X-Frame-Options SAMEORIGIN

Header always set Referrer-Policy strict-origin-when-cross-origin

Header always set Permissions-Policy geolocation=(), microphone=(), camera=()

X-Content-Type-Options nosniff מפחית את האפשרות של הדפדפן לנחש סוגי קבצים ולהפעילם. X-Frame-Options SAMEORIGIN מגביל את ההטמעה של האתר שלכם בדומיינים אחרים ומפחית את הסיכון להתקפות clickjacking. Referrer-Policy קובעת איזה מידע של referer יישלח במהלך הפניית דפים. Permissions-Policy מגבילה הרשאות דפדפן כמו מצלמה, מיקרופון ומיקום.

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

רשימת בדיקה לפני יישום

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

• הורידו את גיבוי קובץ .htaccess הקיים למחשב שלכם.
• ודאו שתעודת ה-SSL שלכם פעילה ומותקנת כראוי.
• הוסיפו כללי הפניה אחד אחד; אל תשנו את כל הכללים בבת אחת.
• בדקו את שגיאות 500, 403 ו-404 ביומני השגיאות של הדפדפן והשרת.
• אל תמחיקו את כללי ה-rewrite של WordPress, Laravel או תוכנות מותאמות אישית.
• בדקו את חובת HTTPS באזורים המוגנים באמצעות סיסמה.
• אם אתם משתמשים ב-CDN, תוסף קאש ותוסף אבטחה, העריכו את הסיכון להתנגשויות.
• נסו את זרימות הכניסה, הטפסים ותשלומים במכשירים ניידים, שולחניים ובדפדפנים שונים.

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

טעויות נפוצות ודרכי פתרון

שגיאת 500 Internal Server Error

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

מסך הסיסמה מופיע שוב ושוב

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

הפניית HTTPS יוצרת לולאת הפניה אינסופית

באתרים מאחורי CDN או פרוקסי, השרת עלול לראות את הבקשה כ-HTTP ולנסות להפנות שוב ושוב ל-HTTPS. במקרה כזה, ייתכן שיהיה צורך בכלל הפניה מיוחד שמתחשב בכותרות כמו X-Forwarded-Proto. גם חשוב שהמודול SSL בלוח הבקרה של ה-CDN יהיה ברמה הנכונה, כמו Full או Full Strict.

תמונות או קבצי CSS לא נפתחים

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

אבטחת .htaccess באתרי WordPress

בקבצי .htaccess של אתרי WordPress יש חשיבות רבה לקישורים הקבועים. לכן, יש להימנע משינוי הכללים שנוצרים על ידי WordPress בין BEGIN WordPress ל-END WordPress שלא לצורך. לרוב, בטוח יותר להוסיף כללי אבטחה מעל או מתחת לחסימות הללו.

צעדים מעשיים שניתן לנקוט עבור WordPress כוללים:

• הוספת הגנת Basic Auth לתיקיית wp-admin.
• חסימת PHP בתיקיית wp-content/uploads.
• אם אינכם משתמשים ב-xmlrpc.php, הגביל את הגישה אליו.
• צמצום הנראות של קבצי readme.html ורישיונות.
• התאמת הפניית HTTPS כך שתהיה תואמת לכתובת האתר של WordPress.

בעיקרון, השימוש גם בסיסמת משתמש WordPress וגם בהגנה באמצעות סיסמת .htaccess עבור wp-admin מספק הגנה כפולה. עם זאת, חלק מהתוספים עשויים להזדקק לגישה לקבצים כמו wp-admin/admin-ajax.php, ולכן יש לבדוק את הפונקציות לאחר מכן. אחסון WordPress שיפור מהירות WordPress

טיפים מקצועיים לאבטחת .htaccess

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

• קחו גיבוי תאריך לפני שינויים קריטיים: htaccess-2026-01-15.bak למשל.
• הימנעו מהוספת מאות כללים מיותרים לקובץ .htaccess אחד.
• הפניות 301 הן קבועות, ולכן קחו בחשבון את זיכרון המטמון של הדפדפן ומנועי החיפוש.
• בדקו את השגיאות בכותרות לאחר הוספת כותרות אבטחה.
• בשטחים המוגנים בסיסמה, צרו משתמשים אישיים במקום להשתמש בסיסמאות חלשות משותפות.
• סגרו את תיקיות הבדיקה, staging והגיבויים ברמת השרת לפני שמנועי החיפוש יראו אותן.

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

סיכום: קובץ קטן, שכבת אבטחה גדולה

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

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

שאלות נפוצות

האם קובץ .htaccess באמת מצפין קבצים?

לא. לרוב המונח הזה מתייחס להגנה על תיקיות באמצעות שם משתמש וסיסמה. הגישה ב-Basic Auth מגבילה את הגישה; אך כדי להבטיח את אבטחת העברת הנתונים יש להשתמש בתעודת SSL על גבי HTTPS.

האם לשמור את קובץ .htpasswd בתוך public_html זה בטוח?

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

מה לעשות אם אני מקבל שגיאת 500 לאחר שינוי קובץ .htaccess?

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

האם נכון להגן על תיקיית wp-admin עם .htaccess?

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

האם הפניית HTTPS מזיקה מבחינת SEO?

הפניית 301 HTTPS המיועדת כראוי אינה מזיקה; להיפך, היא מספקת מבנה URL בטוח ועקבי. הדבר החשוב הוא לא ליצור שרשרת הפניות ולשמור על כל הקישורים הפנימיים תואמים לכתובות HTTPS הסופיות.