[{"data":1,"prerenderedAt":124},["ShallowReactive",2],{"publication:he:P156":3},{"meta":4,"copy":15,"relatedArticles":110,"terms":111,"term":112,"resourceParent":118,"glossaryParent":121},{"id":5,"path":6,"kind":7,"keyword":8,"title":9,"seoTitle":9,"description":10,"incoming":11,"updated":14},"P156","\u002Fglossary\u002Fhsts","term","מה זה HSTS","מה זה HSTS ולמה צריך לתכנן את תחולת המדיניות","HSTS מנחה דפדפן להשתמש ב-HTTPS. הסבר על max-age, תחולת תתי-דומיין, preload ומגבלות ביטול, בלי להעתיק מדיניות ארוכה ללא בדיקה.",[12,13],"\u002Fservices\u002Fdns-ssl","\u002Fservices\u002Fcloudflare","2026-10-29",{"intro":16,"sections":17,"checklist":71,"faq":76,"sources":86,"links":91,"cta":105},"HSTS, קיצור של HTTP Strict Transport Security, הוא מנגנון מדיניות שמנחה דפדפן להשתמש ב-HTTPS עבור מארח. בדרך הרגילה הוא נלמד מכותרת Strict-Transport-Security בחיבור מאובטח. הוא אינו מנפיק תעודה או מתקן HTTPS שאינו עובד. לפני הרחבת המדיניות צריך לדעת אילו מארחים נכללים ואיך מתחזקים אותם.",[18,27,54,61,66],{"title":19,"paragraphs":20,"sources":23},"מה הדפדפן לומד מהמדיניות",[21,22],"הערך max-age קובע לכמה זמן הדפדפן זוכר את הדרישה. includeSubDomains מרחיב את התחולה לתתי-דומיין בהתאם לכללי המנגנון. זו אינה סתם הפניה רגילה מ-HTTP ל-HTTPS: מדיניות זכורה משפיעה על בקשות עתידיות אצל אותו דפדפן.","MDN מתארת גם מצבים שבהם הדפדפן אינו מאפשר להמשיך דרך שגיאת TLS תחת HSTS. לכן לא מוסיפים כותרת ארוכה כדי לקבל סימון בכלי בדיקה בלי לוודא שהמארחים שעליהם היא חלה מוכנים לשימוש יציב ב-HTTPS.",[24],{"label":25,"url":26},"MDN: התנהגות ומגבלות Strict-Transport-Security","https:\u002F\u002Fdeveloper.mozilla.org\u002Fen-US\u002Fdocs\u002FWeb\u002FHTTP\u002FReference\u002FHeaders\u002FStrict-Transport-Security",{"title":28,"paragraphs":29,"table":31},"מה ההבדל בין הפניה, HSTS ו-preload",[30],"הפניה היא תשובת שרת שמשנה את יעד הבקשה. HSTS הוא מידע שהדפדפן יכול לזכור. Preload הוא מסלול נפרד של הכללה ברשימות בדפדפנים, עם תנאים ותהליך משלו; הוספת המילה לכותרת אינה לבדה הוכחה שהדומיין כבר ברשימה.",{"caption":32,"headers":33,"rows":37},"לפני שבוחרים מדיניות",[34,35,36],"נושא","מה לבדוק","סיכון בהתעלמות",[38,42,46,50],[39,40,41],"תוקף HTTPS","כל מארח רלוונטי מגיש חיבור תקין","חסימת גישה עם שגיאת תעודה",[43,44,45],"תתי-דומיין","שירותים קיימים ומתוכננים","הרחבת דרישה למערכת לא מוכנה",[47,48,49],"משך","יכולת תחזוקה והתאוששות","מדיניות נשארת אצל משתמשים",[51,52,53],"Preload","תהליך רשמי ותחולה","הנחה שהוספה או הסרה מיידיות",{"title":55,"paragraphs":56,"sources":59},"למה ביטול אינו תמיד מיידי",[57,58],"הפסקת שליחת הכותרת אינה מוחקת מיד מדיניות שנשמרה. מנגנון העדכון בדפדפן דורש התנהגות תקינה של השירות, ו-preload מוסיף תהליך נפרד. לכן אין להבטיח שתקלה תיעלם בכל הלקוחות ברגע שהערך הוסר בממשק.","מכינים דרך תיקון HTTPS ושומרים אחריות ברורה על תעודות ותתי-דומיין. לא מציעים למשתמשים לבטל הגנות דפדפן כפתרון תחזוקה שגרתי. במצב תקלה מבררים איזו מדיניות חלה בפועל ואיזה חיבור נכשל.",[60],{"label":25,"url":26},{"title":62,"paragraphs":63},"דוגמה: תת-דומיין ישן נשאר ללא HTTPS",[64,65],"התרחיש להמחשה. האתר הראשי תקין, אבל כלי פנימי בתת-דומיין עדיין תלוי ב-HTTP. הרחבת מדיניות לכל תתי-הדומיין בלי מיפוי עלולה לפגוע בגישה אליו. בדיקת העמוד הראשי לבדה לא הייתה מספיקה לקבלת ההחלטה.","אחראי המערכת ממפה את הכלי, בוחן תמיכה ופתרון מתאים ומגדיר מדיניות רק בהיקף שנבדק. אם ספק חיצוני מנהל את השירות, מתאמים איתו במקום לשנות הגדרה רחבה ולגלות את התלות לאחר הפגיעה.",{"title":67,"paragraphs":68},"איך משלבים HSTS בשיפור אבטחה אחראי",[69,70],"רשמו מה נבדק, אילו שמות נכנסים לתחולה ומי שומר על החיבור תקין לאורך זמן. עבדו לפי תיעוד הספק והדפדפנים, ובצעו שינוי בהיקף מאושר עם בדיקות תפקוד. אין ערך max-age אחד שמתאים אוטומטית לכל עסק ולכל שלב מעבר.","HSTS אינו קובע שהאתר אמין, אינו מסיר נוזקה ואינו מצמצם הרשאות מנהלים. הוא שכבה אחת לצד תעודות, ניהול גישה, עדכונים והתאוששות. מדריך אזהרת התעודה מסביר את אבחון התקלה; ערך זה מסביר את המדיניות והשלכותיה.",[72,73,74,75],"HTTPS עובד בכל המארחים הרלוונטיים.","תחולת תתי-הדומיין הוגדרה לפי מיפוי.","מובן ההבדל בין כותרת ל-preload.","יש אחראי לתעודות ולתוכנית טיפול בתקלה.",[77,80,83],{"question":78,"answer":79},"HSTS הוא תחליף לתעודה?","לא, הוא מסתמך על חיבור HTTPS תקין ואינו מנפיק או מחדש תעודה.",{"question":81,"answer":82},"אפשר להעתיק כותרת מאתר אחר?","לא מומלץ בלי לבדוק תחולה, משך, תתי-דומיין ויכולת תחזוקה. מדיניות שמתאימה לאתר אחר יכולה לשבש שירות אצלכם.",{"question":84,"answer":85},"כלי אבטחה סימן שחסר HSTS. האתר נפרץ?","לא, זו תצפית על מדיניות חיבור, לא ראיה לפריצה. צריך לבחון התאמה והקשר לפני שמגדירים אותה.",[87,88],{"label":25,"url":26},{"label":89,"url":90},"IETF RFC 6797: HTTP Strict Transport Security","https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc6797.html",[92,95,98,101,103],{"path":93,"label":94},"\u002Fglossary\u002Fhttps","איך HTTPS שונה מ-HSTS",{"path":96,"label":97},"\u002Fblog\u002Fwebsite-ssl-warning","אבחון אזהרת תעודה",{"path":99,"label":100},"\u002Fblog\u002Fdns-change-checklist","מיפוי מארחים לפני שינוי",{"path":12,"label":102},"טיפול בתעודות ובחיבור",{"path":13,"label":104},"מדיניות חיבור ב-Cloudflare",{"title":106,"description":107,"button":108,"type":109},"רוצים להוסיף מדיניות בלי לשבש שירות?","נמפה מארחים ותלויות ונבדוק חיבור ותעודות לפני הגדרת תחולה או הרחבתה.","לתיאום בדיקת דומיין ותשתית","check",[],[],{"name":113,"aliases":114},"HSTS",[115,116,117],"hsts","strict transport security","מדיניות https",{"path":119,"label":120},"\u002Fresources","כלים ורשימות בדיקה לאבטחת העסק: משאבים שימושיים",{"path":122,"label":123},"\u002Fglossary","מילון סייבר בעברית: מושגים עם הסברים מעשיים",1794134061368]