HOWTO: Change the Security Response Headers on AD FS

Hybrid Identity

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

In this part of the series, we’ll look at the security headers for AD FS implementations.

This blogpost assumes you’re running AD FS Servers as domain-joined Windows Server 2016 Server Core installations. The same information applies to AD FS Servers running Windows Server 2016 with Desktop Experience (Full).


Why look at Security Headers?

To prevent malicious attacks, many new protections for websites utilize security headers. Through security headers, you can prevent malicious scripts from running in browsers visiting your AD FS infrastructure, prevent the acceptance of forged TLS certificates and prevent clickjack attacks.

Reasons why

Through security response headers, the information security level of the AD FS infrastructure can be upgraded to a higher level.

Possible negative impact (What could go wrong?)

When the security response headers to tighten the security of the AD FS sign-in experience are configured wrongly, scripts can be blocked and the entire functionality of the AD FS implementation can be severely crippled.

When AD FS is used in default scenarios, the default settings for the AD FS security response headers can be safely used.


Getting ready

To change the security headers throughout the AD FS infrastructure, make sure to meet the following requirements:


Make sure the AD FS servers run Windows Server 2016, or above, and are installed with the latest cumulative Windows Updates. At a minimum, make sure AD FS Servers running Windows Server 2016 have the July 2019 Cumulative update (KB4507459) installed.

The ability to manage security headers is built into Active Directory Federation Services (AD FS) on Windows Server 2019.


Make sure to sign in with an account that has privileges to manage the AD FS farm.

In case of Windows Internal Database (WID) as the storage method for the AD FS Configuration database, sign in with an account that has local administrator privilege on the primary AD FS server.


How to change the Security Response Headers

There are five security headers of interest:

  1. HTTP Strict-Transport-Security (HSTS)
    The HSTS reponse header indicates to the browser that HTTPS is available and should always be used. This way, the connection cannot be downgraded to HTTP for the time period defined. The recommended value is 31536000 seconds (1 year)
  2. X-Frame-Options
    The X-Frame-Options response header defines the ways the AD FS sign-in experience can be a part of an iFrame. To prevent attacks, it shouldn’t be, so deny is the best option for this header.
  3. X-XSS-Protection
    The X-XSS-Protection response header used to stop web pages from loading when cross-site scripting (XSS) attacks are detected by browsers. This is referred as XSS filtering. The value 1; block is the most effective, as the browser will not render the AD FS sign-in experience when an XSS attack is detected.
  4. Cross-origin Resource Sharing (CORS)
    Web browsers prevent web pages from making cross-origin requests initiated from within scripts. This can be enabled to allow accessing resources in other origins (domains). CORS is disabled by default and should remain disabled.
  5. Content-Security-Policy (CSP)
    The CSP response header is used to prevent cross-site scripting, clickjacking and other data injection attacks by preventing browsers from inadvertently executing malicious content.

The step to enabling the above security response headers is to run the following line of Windows PowerShell in an elevated PowerShell window:

Set-AdfsResponseHeaders -EnableResponseHeaders $true

It should be enabled by default, but if not, running the above line of Windows PowerShell sets the X-Frame-Options security response header to deny on Windows Server 2016.

On Windows Server 2019, it enables the other four security response headers, too.

Then, run the following three lines of Windows PowerShell in an elevated PowerShell window:

Set-AdfsResponseHeaders -SetHeaderName "Strict-Transport-Security" -SetHeaderValue "max-age31536000; includeSubDomains"

Set-AdfsResponseHeaders -SetHeaderName "X-XSS-Protection" -SetHeaderValue "1; mode=block"

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:"


This will enable the above security response headers with the following settings:

Table of Security Response Headers for AD FS

AD FS uses JavaScript in the authentication process and therefore enables JavaScript by including ‘unsafe-inline' and ‘unsafe-eval' sources in default policy. While this is not the safest value for the Content Security Policy header, it’s needed to allow the onload.js script to run, to enable customizations of this Javascript and/or to replace the built-in Javascript to switch to the Paginated User Experience for AD FS.


Testing Security Response Headers offers a great web interface to query the security response headers of your AD FS infrastructure.


Rolling back Security Response Headers

To roll back the above changes to the security response headers in AD FS, run the following three lines of Windows PowerShell in an elevated PowerShell window:

Set-AdfsResponseHeaders -RemoveHeaders "Strict-Transport-Security"

Set-AdfsResponseHeaders -RemoveHeaders "X-XSS-Protection"

Set-AdfsResponseHeaders -RemoveHeaders "Content-Security-Policy"



Deep in the basement of AD FS, a couple of values live, that true security admins will try to tame: security response headers. Use the information in this blogpost to tame these response headers and prevent common attacks against AD FS.

Further reading

Customize HTTP security response headers with AD FS 2019
An Introduction to HTTP Response Headers for Security
The 8 HTTP Security Headers Best Practices
HTTP Security Headers: 5 Headers You Must Implement on Your Site
Hardening your HTTP response headers

Series Navigation

<< HOWTO: Enable Azure Multi-factor Authentication on AD FSHOWTO: Design a networking infrastructure for Hybrid Identity components >>

7 Responses to HOWTO: Change the Security Response Headers on AD FS


    X-XSS-Protection is a bit dangerous to enable as it doesn't allow that many browsers to access AD FS afterwards. See the "Web browser compatibility" section at


    Is it usefull with WAP?
    Changing HSTS does not seem to be effective with WAP.


    CORS does not work on WAP.We added the CORS headers to ADFS but this does not seems to affect the WAP. How can we set CORS on the WAP?

    • As far as I know, you can't get Cross-Origin Resource Sharing (CORS) on the Web Application Proxy servers.
      The Web Application Proxy servers themselves do not host any content, but proxy the AD FS servers. The AD FS servers can have CORS properly configured, but the Web Application Proxy servers may not relay the header.


    Keep in mind that for some reason, Microsoft chose to only implement HSTS on some endpoints. For example /adfs/ls but not the root directory or even /federationmetadata.


    Hello!, does this mean you can not enable HSTS on 2012R2 WAPs?

    • Unfortunately, the Get-AdfsResponseHeaders and Set-AdfsResponseHeaders Windows PowerShell cmdlets are not available on Windows Server 2012 R2.


leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.