<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
Understanding X-XSS-Protection HTTP Header Vulnerability
Single Sign-On
Okta Classic Engine
Okta Identity Engine
Overview

The goal of this knowledge is to clarify if Okta is vulnerable to the X-XSS-Protection HTTP Header exploits.

Applies To
  • X-XSS-Protection HTTP Header
  • Single Sign On (SSO)
  • Browser based vulnerability
Cause

Some browsers, including Internet Explorer, contain built-in filters designed to protect against cross-site scripting (XSS) attacks.

This behaviour does not in itself constitute a vulnerability; in some cases, XSS filters may themselves be leveraged to perform attacks against application users. However, in typical situations, XSS filters do provide basic protection for application users against some XSS vulnerabilities in applications. 

Solution
  • X-XSS-Protection is deprecated in most modern browsers. Chrome, Firefox, and Edge are no longer checking this header. For more information, see: X-XSS-Protection. The recommended solution is to implement strong CSP policies instead. In addition, Okta trains its employees on secure coding practices and strongly enforces input validation and output encoding to prevent XSS.
  • X-Content-Type-Options: nosniff is currently in production where applicable. For example, there is no risk of XSS on a static page like robots.txt since it does not allow user submission (either data input or upload) so the lack of the X-Content-Type-Options header on this page is not a vulnerability.
  • Applications can instruct browsers to disable this filter by setting the following response header: X-XSS-Protection: 0
Loading
Understanding X-XSS-Protection HTTP Header Vulnerability