mobileFX WebKitX ActiveX
Advanced Topics / Content Filtering
In This Topic
    Content Filtering
    In This Topic

    WebKitX Content Filtering is a mechanism that allows you to remove HTTP Response Headers, such as Content Security Policy (CSP) response header, and alter or remove Cross Origin Resource Sharing (CORS) response header. WebKitX implements in CEF3 Client I/O Thread a custom Resource Handler that intercepts normal HTTP and HTTPS requests and spawns a light-weight object that downloads the resource instead. Once the HTTP Response Headers for a particular resource are available, they are being filtered-out and passed to the IO thread for further processing.

     

    This mechanism works for the following HTTP methods: GET, POST, HEAD, DELETE and PUT, and works for any MIME type resource. WebKitX content filtering works both with HTTP and HTTPS requests, meaning that it works perfectly with server-side SSL encryption, but it does not work if client-side SSL authentication is enabled. Please read further below for more information about Microsoft IIS Client SSL certificate configuration.

     

     

    Overwrite Cross-Origin Resource Sharing (CORS)

    Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin. A web application makes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, and port) than its own origin.

    An example of a cross-origin request: The frontend JavaScript code for a web application served from http://domain-a.com uses XMLHttpRequest to make a request for http://api.domain-c.com/data.json.

    For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest and the Fetch API follow the same-origin policy. This means that a web application using those APIs can only request HTTP resources from the same origin the application was loaded from, unless the response from the other origin includes the right CORS headers.

     

     

    The CORS mechanism supports secure cross-origin requests and data transfers between browsers and web servers. Modern browsers use CORS in an API container such as XMLHttpRequest or Fetch to help mitigate the risks of cross-origin HTTP requests.

    This cross-origin sharing standard is used to enable cross-site HTTP requests for:

    To enable CORS, you need to configure your web server to return the Access-Control-Allow-Origin HTTP header: Access-Control-Allow-Origin: * Access-Control-Allow-Origin: <origin>

    In WebKitX you can overwrite web server's Access-Control-Allow-Origin by handling the OnCreate() event and setting Settings.filter_response = true and Settings.access_control_allow_origin to "*" or the domain you wish to allow.

     

    Overwrite Content Security Policy (CSP)

    WebKitX due to JavaScript injection features and extensive use of eval() requires Content Security Policy (CSP) to be suppressed. If you try to load a URL with CSP enabled in WebKitX, it will result in a series of error messages related to unsafe-eval, like the one below:

     

     

    Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware. CSP is designed to be fully backward compatible. Browsers that don't support it still work with servers that implement it, and vice-versa: browsers that don't support CSP simply ignore it, functioning as usual, defaulting to the standard same-origin policy for web content. If the site doesn't offer the CSP header, browsers likewise use the standard same-origin policy.

    To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header (sometimes you will see mentions of the X-Content-Security-Policy header, but that's an older version and you don't need to specify it anymore).

    In WebKitX you can overwrite web server's Content-Security-Policy by handling the OnCreate() event and setting Settings.filter_response = true and Settings.remove_response_headers to "x-webkit-csp,content-security-policy,x-content-security-policy". The same feature can be used to remove any other response header.

     

     

    Some sites stop loading after enabling Content Filtering

    WebKitX Content Filtering features and SSL Client Certificate enabled on your Web Server cannot work together. You must either disable WebKitX Content Filtering or disable SSL Client Certificate on your Web Server, as illustrated below:

     

     

    Page Encoding problems with early implementation of Content Filtering

    CEF 3.3202.1692 ignores Content-Type charset option when using custom CefResourceHandler, causing pages such as Google.gr or Google.de to render with unreadable characters. [bug link]. To treat this problem, WebKitX Content Filtering enforces UTF-8 BOM insertion in text/plain, text/html, application/json, application/javascript, application/ecmascript, text/css, text/xml MIME types. Please note that the bug appears only if content filtering is enabled and does not affect normal (unfiltered) browsing or editing. The plan about this bug is to switch to newer version of CEF3 on January 2019.

    Loading www.google.gr with content filtering with version 1.5.11.3220:

     

    Loading www.google.gr with content filtering with version 1.5.11.3297 (Sep 2018) and later: