Pour compléter la réponse de voretaq7 , vous pouvez également utiliser le fichier Web.config (Remarque: à utiliser uniquement pour les sites SSL, car il ajoutera l'en-tête des réponses HTTP et HTTPS, ce qui est contraire à la spécification RFC 6797, voir l'explication ci-dessous) - ajoutez un bloc comme suit:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000"/>
</customHeaders>
</httpProtocol>
</system.webServer>
De toute évidence, vous avez peut-être déjà un system.webServerbloc dans votre Web.config, alors ajoutez ceci à cela, si c'est le cas. Nous préférons gérer les éléments dans le fichier Web.config plutôt que dans l'interface graphique, car cela signifie que les modifications de configuration peuvent être validées dans notre référentiel Git.
Si vous voulez gérer la redirection HTTP vers SSL, comme l'a mentionné Greg Askew , vous trouverez peut-être plus facile de le faire avec un site Web distinct dans IIS. C’est ainsi que nous traitons l’exigence de SSL pour certains sites clients. Ce site ne contient qu'une redirection HTTP et quelques correctifs en matière de divulgation d'informations , le tout dans le fichier Web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpRuntime requestValidationMode="2.0" enableVersionHeader="false" />
</system.web>
<system.webServer>
<httpRedirect enabled="true" destination="https://www.domain.co.uk/"
httpResponseStatus="Permanent" />
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
</customHeaders>
</httpProtocol>
<rewrite>
<outboundRules>
<rule name="Remove RESPONSE_Server">
<match serverVariable="RESPONSE_Server" pattern=".+" />
<action type="Rewrite" value="" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>
Ceci est notre solution préférée pour plusieurs raisons: nous pouvons facilement enregistrer le trafic redirigé séparément (comme il se trouve dans un journal IIS différent), cela n'implique pas plus de code dans Global.asax.cs (nous n'avons pas de code ce qui est un peu plus pratique pour un site Umbraco) et, ce qui est important, cela signifie que toute la configuration est toujours conservée dans notre repo GIT.
Modifié pour ajouter: pour être clair, afin de se conformer à la RFC 6797 , l'en- Strict-Transport-Securitytête personnalisé NE DOIT PAS être ajouté aux demandes effectuées par HTTP non chiffré. Pour être conforme à RFC6797, vous DEVEZ avoir deux sites dans IIS, comme je l’ai décrit après le premier bloc de code. Comme le souligne Chris , le RFC 6797 comprend:
Un hôte HSTS NE DOIT PAS inclure le champ d'en-tête STS dans les réponses HTTP acheminées via un transport non sécurisé.
par conséquent, l'envoi de l'en- Strict-Transport-Securitytête du client en réponse à une demande non SSL ne serait pas conforme à la spécification.