Skip to main content

​
Strip or Inject Headers With the Header Filter

Open Configure → Restriction Policies → Privacy control → Header filter. This section sits under the Privacy control menu group alongside Cookie filter, Header filter and Elevated Privacy — configure them together, since a Cookie filter allow row and an Elevated Privacy STANDARD row can otherwise fight over the same header. The Header-filtering section (safesquid-header-filtering(5)) allows administrators to strip out or inject HTTP headers into client requests or server responses.

​
Core mechanics

Allow/Deny list order (first match wins, unlike Cookie filter’s last-match rule), Insert with variable expansion.
  • Dual-List Policy Engine: Header filtering utilizes a global Allow/Deny switch. If the global policy is set to Allow, SafeSquid first scans the Deny List to strip headers (action = FALSE), then evaluates the Allow List to preserve exceptions.
  • Insertion Engine: Independent of the filter list, the Insert list injects entirely new headers into the stream. The inserted headers undergo variable expansion, meaning runtime variables (like usernames or IP addresses) can be dynamically injected into the header value.
  • Flags Targeting: Both filter and insert rules target either the Request, Response, or Both (which & flags).

​
How SafeSquid processes the lists

  1. For each header field on the message being filtered:
  2. If Policy is Deny, SafeSquid walks Allow first, then Deny.
  3. If Policy is Allow, SafeSquid walks Deny first, then Allow (Allow can restore a field Deny removed, and vice versa on the second pass).
  4. Within each list pass, the first matching row decides allow or strip for that field.
  5. Stripped fields are removed and logged as removed in native header logs.
  6. Insert runs after allow/deny. Both Type and Value must be non-empty; Value supports connection variables.
  7. A field that is kept (not stripped) is logged as allowed, alongside the removed note in step 5.
  8. Insert rows are cumulative, not first-match — more than one enabled, matching Insert row can add a header to the same message.
Order matters. On Allow/Deny rows, put specific regexes above broad ones — first match in that list pass wins for each field.

​
Section fields

The console splits Header filter into five tabs. Allow and Deny share one row form, so the fields are documented once under Allow; Insert reuses the same fields with different meanings, called out in that tab.

​
Global fields

  • Enabled (enabled) — turns Header filter on or off for all connections, unless the matching Access entry’s Bypass grants Header filtering.
  • Policy (policy) — the default outcome when no Allow/Deny row matches a header field: Deny strips it, Allow forwards it. It also decides which list is walked first (see step 2–3 above).

​
Examples

Open Configure → Restriction Policies → Privacy control → Header filter. Five sub-tabs: Global (Enabled/Policy), Allow, Deny, Insert, and View headers — the last lets you inspect real header names and values from a live connection before writing regexes.
SafeSquid console showing the Privacy control Header filter Global tab with its five sub-tabs, the Edit Policy icon circled

Privacy control — Header filter Global tab

​
Strip Referer on all users except marketing

  • Policy: Deny
  • Allow row: Profiles Marketing, Type Referer, Applies to CLIENT HEADER
Result: every client request loses the Referer field except connections with the Marketing profile, which keep it.

​
Insert a custom request header

  • Insert row: Type X-Proxy-User, Value $_USERNAME_$, Applies to CLIENT HEADER
Result: after filtering, matching connections get X-Proxy-User added to the forwarded request with the expanded username variable.

​
Enforce a Content-Security-Policy correctly

  • Deny row: strips the response’s own Content-Security-Policy field on all connections.
  • Insert row: applies the minimal-access CSP tier to all connections by default.
  • Insert row: gated to a line-of-business Profile, applies the standard-access tier instead.
Result: every response gets a clean, SafeSquid-authored CSP instead of a merged one. Most sites run under the tight, same-origin-only policy. The one tool that needs to reach its own backend gets the slightly more permissive tier.

​
Allow everything, hide the server banner

  • Policy: Allow
  • Deny row: Type Server, Applies to SERVER HEADER
Result: the Server field is stripped from every response, hiding the origin’s web-server signature. All other fields pass through unless another Deny row matches.

​
How to verify

  1. Use View headers in the Web UI to capture real header names and values before writing regexes.
  2. Enable HEADER in LOG_LEVEL and read native removed: / added: lines.
  3. Open Reports → Detailed logs while reproducing from a known client.
  4. Enable System configuration debug response headers (see Debug response headers) to inspect policy outcomes on the wire.
  1. Use browser devtools to confirm the Content-Security-Policy header a page actually received matches the tier you intended. A page that looks broken after adding a CSP entry is the classic symptom of the site’s own CSP not having been stripped first.

​
Next steps

  • Cookie filter - control which HTTP cookies pass between clients and servers using a global policy plus allow and deny override lists.
  • Elevated Privacy - reduce cross-site tracking by stripping third-party cookies and selected tracking headers.
  • Suggested Profiles - legacy reference: the autocomplete catalog of ready-made profile names in the Web UI. This section is not in the current Configure console.