We recently conducted a security audit, during which two issues were flagged related to our use of Universal Login:
HSTS enforcement.
Content-Security-Policy directives to prevent script injection attacks.
However upon reviewing traffic between the application and the authorization server, I observed that all communication occurs over HTTPS. However, the audit specifically flagged the lack of HSTS enforcement on the authorization server. Could this issue be related to the domain not being preloaded in the HSTS preload list, or is there another reason HSTS might be reported as missing?
For the Content-Security-Policy concern, I noticed the Universal Login page includes a directive to prevent iframe loading, but the audit indicated there were no directives explicitly addressing script injection.
How can I configure or extend the directives for the Universal Login page to address this security concern and mitigate the flagged vulnerability? Thank you in advance!
I appreciate your patience! I’ve heard back from the security team. Please see the below:
Regarding HSTS enforcement: Okta utilizes HSTS in all communication between Okta and the customer. The HSTS header is set at the top domain level. As long as the user visits “https://[customer subdomain].okta.com” then only https will be used as all pages under the domain would inherit the HSTS requirement.
Regarding Content-Security-Policy directives to prevent script injection attacks: We want to assure you that we take the security of our application seriously here at Okta, and have below controls in place which are audited and attested as part of our various certifications. Okta’s current certifications are always available at security.okta.com
Code Review and Sanitization
Content Security Policy (CSP)
Regular Security Audits, including vulnerability scans and
External Third-Party Penetration Test.
Also, I see that you’ve opened a support ticket. Please continue working with support on this issue.