<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
Sanitizing HTTP Traces
Okta Classic Engine
Devices and Mobility
Multi-Factor Authentication
Okta Identity Engine

Overview

For troubleshooting purposes, Okta Support may request an HTTP trace file (for example, Chrome’s .HAR export, SAMLTracer, Fiddler, or ZAP outputs) to see the authentication flow.  The HTTP trace will record all details of the requests and responses. This includes the data exchanged, the server response, and, if present in the authentication request, passwords, session tokens, cookies, and other confidential information.

Sensitive information such as API keys, secrets, cookie values, or passwords should be redacted for security reasons.

There is a HAR file sanitizer built into case file uploads that attempts to redact all sensitive information (API keys, secrets, cookie values, or passwords) in the file.  When HAR files are uploaded to a support Case, automation is triggered that redacts the HAR file at the customer side before the file is actually uploaded to the Case.  This is the name of the process that details how to upload a HAR file to a case: How to Sanitize a HTTP Trace File Automatically

NOTE: If a HAR file is available, upload it to a support Case for the file to be auto-redacted.   Note that Fiddler traces can be exported to HTTP Archive v1.1 or v1.2.  

NOTE: There is no attempt to remove user information as part of the sanitization process. We recommend using a test user account when capturing a .HAR file.  

This document outlines what is sanitized, what is not sanitized, what may be missed by automatic sanitization, and when manual redactions may be necessary. Lastly, it provides examples of manual redactions.

Procedure: File Upload Sanitizer

Using the How to Sanitize a HTTP Trace File Automatically process triggers the File Upload Sanitizer
 

What is sanitized during file upload?

  • All Cookies are redacted. 
    • Replaced with the first characters of a hash.  
    • A few internal-use cookies have a different redaction strategy to allow support to troubleshoot. 
  • The signature from security tokens (ID tokens, access tokens, SAML responses) is redacted.
  • Some field values are removed based on a list of commonly used sensitive field names.
  • Many response types, such as images, fonts, JavaScript, and CSS, have their content removed.

 

What is not sanitized during file upload?

All claims in JWT tokens and attributes in SAML assertions are left intact to aid in troubleshooting authentication flows.
 

What may be missed during file upload?

If a password is entered while capturing the HTTP trace, check that the password was redacted by:

  • Downloading the sanitized HAR file
  • Open it with a text editor and search for the password string that was entered.
  • If the password is not found, the sanitized field is okay to submit. 
  • If the password is found:
    • Open the original HAR file, replace the password with "[redacted]", save it, and re-attach it to sanitize it.

 

When should the HTTP Trace file be sanitized manually?

In these situations, consider manually redacting the HTTP Trace. 

  • The file is not a HAR file or SAML Tracer file.
  • Password field with an uncommon name.
  • Some vendor-specific fields with uncommon names

 

NOTE: If there are any concerns about sensitive information that the file upload sanitizer may miss, consider manually redacting the file. 

NOTE: HTTP traces other than HAR and SAML Tracer will need to be manually redacted. 

 

Related References

Loading
Sanitizing HTTP Traces