Application page not rendering fully due to blocked WOFF/WOFF2 objects.
search cancel

Application page not rendering fully due to blocked WOFF/WOFF2 objects.

book

Article ID: 387665

calendar_today

Updated On:

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Users successfully accessing internet sites via Cloud SWG using multiple access methods (IPSEC on site and WSS Agent for roaming users).

SAML authentication enabled with IP surrogates, implying no CORS issues.

When users access a specific application, the page seems to render correctly but certain objects on the page are missing.

HAR file shows that certain requests generated by the Application receive 403 responses - no access denied pages appear on the page, due to the nature of the application architecture.

All blocked requests triggering the 403 response are for WOFF/WOFF2 files, which is a web font format and explicitly allowed by the Cloud WSG admin with a 'Contents and limits' font file type content filtering rule.

Cloud SWG access logs indicate that a content filtering rule is blocking the above requests.

Environment

Cloud SWG.

Web sites using WOFF/WOFF2 fonts.

Executables are blocked per content filtering 'Contents and limits' file types.

Cause

OCS sending WOFF/WOFF2 objects with an invalid content-type response header.

Octet-streaming content-type is considered an EXECUTABLE mime type which is blocked per the customers policy.

Resolution

A number of options exist to address this:

  • Work with OCS to have them correct the content-type with the WOFF/WOFF2 files
  • Add an content-filtering rule that explicitly allows executables from this problem OCS domain
  • Enable SSL interception bypass for the domain these objects are being downloaded from so that the match fails

Additional Information

HAR file shows the exact URL being blocked.

Generating a curl request to that endpoint, we clearly see an invalid content-type response

> GET /#####/fonts/example.woff HTTP/1.1
> Host: example.com
> User-Agent: curl/8.7.1
> Accept: */* 

< HTTP/1.1 200 OK
< Content-Type: application/octet-stream
< Last-Modified: Thu, 23 Jan 2025 10:57:08 GMT
:
< Cache-Control: public, max-age=30839000
< Date: Fri, 31 Jan 2025 14:25:33 GMT
< Transfer-Encoding:  chunked
< Connection: keep-alive
< Connection: Transfer-Encoding

As per the RFC, the content-type returned for this object type should be font/woff or font/woff2.

Running a Cloud SWG Portal report on this domain, and looking at the matching 'Rule ID', we see that the request was blocked by a specific rule.

The blocking rule has several conditions based on EXECUTABLES or Applications. Looking through each conditions, it was the 'Application' block and most likely the EXECUTABLES block.

Looking at the specific conditions used to detect executables, we can see that our content-type falls into it.

define condition executable_mime_type
    response.header.Content-Type="(?i)application/octet-stream" 
    response.header.Content-Type="(?i)application/x-msdownload" 
    response.header.Content-Type="(?i)application/x-msdos-program" 
    response.header.Content-Type="(?i)(application|image)/(x-|x-ms|x-win-|)(metafile|wmf)" 
:
end