تصمیمات اتخاذ شده در RFC 6796 ، 8.1 درک بسیار آسان تر است ، اگر تصور کنید چه اتفاقی می افتد ، اگر یک سرصفحه HSTS از پاسخ HTTP همانند HTTPS استفاده شود:

• این سایت فقط HTTP است و به طور تصادفی یک هدر HSTS اضافه می کند. اکنون به مرورگر دستور داده می شود تا به HTTPS ارتقا یابد ، اما این سایت به هیچ وجه نسخه HTTPS را ارائه نمی دهد و غیر قابل دستیابی می شود.

• یک مرد در میانه (MitM) این هدر را اضافه می کند ، و سایت را غیر قابل دستیابی می کند.

همانطور که یک فرد در وسط نیز می تواند همین کار را از طریق اتصال HTTPS انجام دهد ، وقتی کاربر یک هشدار را از یک استثناء امنیتی رد می کند ، RFC 6796، 8.1 دو شرط دارد:

• هدر HSTS باید از طریق حمل و نقل مطمئن (نه HTTP واضح) دریافت می شود.

• هیچ خطای حمل و نقل ایمن و یا هشدارهای اساسی وجود ندارد. همانطور که پس از اجرا ، HSTS به همان شرایط نیاز دارد ، همانطور که در 8.4 توضیح داده شد ، داشتن هرگونه خطا یا اخطار مجاز در هنگام خواندن هدر ، باعث می شود سایت غیرقابل دسترسی باشد ، خواه تصادفی باشد و هم ناشی از یک MitM باشد.

بنابراین ، تنها استفاده معقول از HSTS عبارتند از:

• ابتدا HTTP را به HTTPS هدایت کنید ، سپس به نام متعارف از طریق HTTPS تغییر مسیر دهید.
• هدر HSTS را به تمام نام های میزبان HTTPS تغییر دهید ، نه فقط به نام میزبان متعارف. به این ترتیب از تمام نامهای میزبان محافظت خواهید شد. در غیر این صورت ، یک نسخه محافظت نشده هنوز هم می تواند برای MitM استفاده شود.
• اگر تمام میزبان های هدایت شونده زیر دامنه نام میزبان متعارف هستند ، و اگر به HTTP ساده به HTTP ساده احتیاج ندارید ، دستورالعمل شامل SubDomains را اضافه کنید. برای محافظت از همه آنها به طور همزمان.
• HSTS را از قبل بارگذاری کنید. این دو مرحله دارد: اضافه کردن هدر و ارسال به لیست ها.