Isolation behavior with the advanced policy setting http.request.client_post.post_to_different_host
search cancel

Isolation behavior with the advanced policy setting http.request.client_post.post_to_different_host


Article ID: 205004


Updated On:


Web Isolation Cloud Web Isolation


This article describes the use of the feature http.request.client_post.post_to_different_host and the expected behavior when enabled or disabled.


The setting can be found under Rule Internal Advanced Settings


Setting is Enabled

This setting is applied when the server-side browser issues a POST request to a different host which affects the top-level navigation such as when a form is submitted. The Threat Isolation Engine (TIE) will send the POST payload to the user's browser, then the Web Isolation Web Application will have the browser send the POST request.


In this example, a simple form is served by with a form action to POST some data to https://proxysg.symcdemos.local/post/url

The HTML content of is served as:

<!DOCTYPE html>
<title>POST Form Data</title>

<h1>POST Form Data Example</h1>

<form action="https://proxysg.symcdemos.local/post/url" method="post">
        <label for="input">Enter data to send:</label>
        <input name="input" id="input" value="Hello World">
        <button>Submit Form</button>



Browsing to it through Isolation renders the page as below with in the browser's address bar.

Once the button Submit Form is clicked, Isolation sends a URL update request for https://proxysg.symcdemos.local/post/url with the POST data "input=Hello+World". This can be seen in the Web Socket messages as below:

The top-level navigation is performed where the address bar URL is changed to https://proxysg.symcdemos.local/post/url and the POST request is sent.


Setting is Disabled

This feature is disabled by default. When disabled, the TIE will send a normal URL update request to the user's browser which is triggered as a GET request. In this case, the POST payload is not shared with the user's browser.


Using the same test web application as above, clicking the button triggers a normal URL update request. This is shown in the Web Socket messages as:


The request is now sent as a GET:


What about POST requests not involving top-level navigation?

POST requests generated in the background which do not trigger a top level navigation are not included. For example, POST requests generated by an XMLHttpRequest javascript function.