Header filter

Overview

Control how the SafeSquid modifies the HTTP header messages exchanged between your Internet Clients like web browsers and the requested web service.

You can add a new header directive, delete a header directive or modify an existing header directive.

The request and response headers are processed by this section before they are processed by the facility to rewrite headers in the Content Re-Write section.

This section consists of 4 sub-sections – Global, Allow, Deny and Insert.

The processing of a request or a response, by this section is bypassed if the Global sub-section is set to False, and the policies in Allow / Deny / Insert thus become muted.

The policies in the Insert section are processed after the policies in Allow / Deny lists.

Setting the Default Policy to Allow in the Global Sub-Section, permits all HTTP headers to be exchanged, unless there is a policy directive in the Deny List to prevent a header from being exchanged.

Similarly setting the Default policy to Deny shall block all non-mandatory HTTP headers from being exchanged, unless a policy in the Allow list, explicitly permits.

Global

Enabled

Enable or Disable header filter section.

• TRUE : Enable header filter section.
• FALSE : Disable header filter section.

Policy

Select the default action to take, when no matching entry for a requested header is found.

• ALLOW : Allow everything Except rules defined under Deny subsection.
• DENY : Deny everything Except rules defined under Allow subsection.

Allow

When the Policy is Deny, rules defined under this sub-section, are exclusively allowed access.

Here you can add a new allow entry, that would explicitly result in acceptance or allowance of header filter to all or specific set of conditions.

Enabled

Enable or Disable this entry

• TRUE : Enable this entry
• FALSE : Disable this entry

Comment

For documentation, and future references, explainthe relevance of this entry with your policies.

Profiles

Specify the Profiles applicable for this entry.

This entry will be applicable only if the connection has any one of the specified profiles.

Leave it Blank, to apply for all connections irrespective of any applied profile.

To avoid application to a connection that has a profile, use negated profile (!profile).

Type

A regular expression matching the header type to which this entry applies to.

Headers are in the form of type and value.

Leave blank to Match everything.

Example : X-GoogApps-Allowed-Domains.

Value

A regular expression matching the header value's this entry applies to leave blank to match everything.

Leave blank to Match everything.

Example : text/html.

Applies to

This option is to select whether this entry applies to the server header, client header, or both.

• CLIENT : This entry will be applied only for request headers, sent by the client.
• SERVER : This entry will be applied only for response headers, sent by the server.

Example

Rule#1

I want to allow websockets for connections which are profiled as “ALLOW WEBSOCKET”

This allow rule can be used in a situation where for all users connections to websockets are denied.

Using Allow rule we can allow websockets connections to a defined application/service and for a defined user-group.

Deny

When the Policy is Allow, rules defined under this sub-section, are denied access exclusively.

Here you can add a new 'allow' entry, that would explicitly result in blocking or denial the header filter to all or specific set of conditions.

Enabled

Enable or Disable this entry

• TRUE : Enable this entry
• FALSE : Disable this entry

Comment

For documentation, and future references, explainthe relevance of this entry with your policies.

Profiles

Specify the Profiles applicable for this entry.

This entry will be applicable only if the connection has any one of the specified profiles.

Leave it Blank, to apply for all connections irrespective of any applied profile.

To avoid application to a connection that has a profile, use negated profile (!profile).

Type

A regular expression matching the header type to which this entry applies to.

Headers are in the form of type and value.

Leave blank to Match everything.

Example: X-GoogApps-Allowed-Domains.

Value

A regular expression matching the header value's this entry applies to leave blank to match everything.

Leave blank to Match everything.

Example: text/html.

Applies to

This option is to select whether this entry applies to the server header, client header, or both.

• CLIENT : This entry will be applied only for request headers, sent by the client.
• SERVER : This entry will be applied only for response headers, sent by the server.

Example

Rule#1

I want to deny all websocket connection using the request headers with header "websocket"

For connections with profile “REMOVE WEBSOCKETS” "websocket: upgrade" header will be removed from request headers, which will result in websocket connection to never be established.

Insert

In this sub section you can add the rules to modify the request and response headers.

You can insert additional information in the headers sent by your browser.

Enabled

Enable or Disable this entry

• TRUE : Enable this entry
• FALSE : Disable this entry

Comment

For documentation, and future references, explainthe relevance of this entry with your policies.

Profiles

Specify the Profiles applicable for this entry.

This entry will be applicable only if the connection has any one of the specified profiles.

Leave it Blank, to apply for all connections irrespective of any applied profile.

To avoid application to a connection that has a profile, use negated profile (!profile).

Type

A regular expression matching the header type to which this entry applies to.

Headers are in the form of type and value.

Leave blank to Match everything.

Example: X-GoogApps-Allowed-Domains.

Value

A regular expression matching the header value's this entry applies to leave blank to match everything.

Leave blank to Match everything.

Example: text/html.

Applies to

This option is to select whether this entry applies to the server header, client header, or both.

• CLIENT : This entry will be applied only for request headers, sent by the client.
• SERVER : This entry will be applied only for response headers, sent by the server.

Example

Rule#1

We want our users to use only our corporate google account.

When users try to login using his/her personal google account they should not be able to login.

Using the custom header in request X-GoogApps-Allowed-Domains we can specify which domains are to be allowed.

Make sure that the list includes the domain you registered with Google Workspace

Rule#2

We allow our users to watch YouTube during lunch hours, however we do not want user to watch inappropriate contents.

We want to enforce YouTube strict mode for all users.

Using header insert we can insert custom header YouTube-Restrict: To set strict restricted access.

However as per google YouTube strict does not filter 100% of inappropriate contents.

View headers

In this sub section you can find the example headers with type and values.