Privacy control groups the three sections that shape what leaves and enters the browser: Cookie filter governs Cookie/Set-Cookie headers, Header filter governs every other request/response header, and Elevated Privacy applies a single tiered privacy level (cookies, then Referer/Origin, then User-Agent) on top of both. Configure them together — a Cookie filter allow row and an Elevated Privacy STANDARD row can otherwise fight over the same header.
Cookie filter
Header filter
Elevated Privacy
The Cookies-filtering section (safesquid-cookies-filtering(5)) provides granular control over HTTP cookies passing between clients and servers.
Dual-list Allow/Deny walk, last match in pass wins — unlike most other sections’ first-match rule.
Dual-List Policy Engine: Cookie filtering operates on a Global Policy (Allow or Deny) combined with Allow/Deny override lists. If the global policy is set to Allow, SafeSquid first scans the Deny List (to block matching cookies) and then scans the Allow List (to explicitly permit exceptions).
Time-Based Evaluation: Unlike other modules, the time profiles here (limitmonths, limitdays, etc.) are checked against the cookie’s literal Expires attribute (COOKIE_HAS_EXPIRES), not the proxy’s current system time.
Action: Matches result in the cookie being silently stripped from the HTTP stream (HEADER_FILTERED).
If Policy is Deny, SafeSquid walks Allow first, then Deny.
If Policy is Allow, SafeSquid walks Deny first, then Allow.
Within each list, every enabled matching row is evaluated; the last match in that list pass sets the outcome (not first-match like Access restrictions).
Each Cookie header field is processed separately; denied fields are erased from the header list.
Domain, path, and expiry filters on a row apply only when Direction is IN (Set-Cookie). The live request/response header hooks call filtering with outbound (Cookie) direction only — Set-Cookie rows are configured for server→browser cookies but are not applied by the active filter_cookies path in this tree.
Order matters. Put specific host or profile rules above broad catch-alls. Because the last match in a list pass wins, a lower row can override an upper row in the same list.
IN direction is configured but not enforced. Domain/Path/expiry filters on IN (Set-Cookie) rows are evaluated in code, but the active filter_cookies path only calls filtering for OUT (browser→server Cookie) direction. Do not rely on an IN row to block a server’s Set-Cookie in the current build.
Profiles — Limit the row to connections that carry these Access Profile tags. Blank ignores profiles. Prefix ! negates a tag.
Direction — OUT — browser→server Cookie headers (what the live hooks filter). IN — server→browser Set-Cookie (domain, path, expiry tests in code; not invoked by current hooks). BOTH — either direction when filtering runs.
Domain / Path — Regular expressions. Used for Direction IN when Set-Cookie filtering runs. For OUT rows, only profiles and direction are tested.
Expiry ranges / Time match mode — Apply only to Set-Cookie with a parseable Expires attribute. ABSOLUTE — one continuous window from start through end fields. ALL RANGES — expiry must satisfy every configured range at once.
Open Configure → Restriction Policies → Privacy control → Cookie filter. The Global
sub-tab holds the Enabled switch and the Policy (Allow/Deny); Allow and Deny are
separate sub-tabs holding the override row lists.
Allow row: Profiles Staff, Direction OUT, Domain corp\.example\.com
Result: staff users keep Cookie headers for corp.example.com; all other outbound cookies on matching requests are stripped and Clear-Site-Data: "*" is added when any cookie is dropped.
From a test client, browse a site that sets cookies and watch the browser devtools Network tab for request Cookie headers upstream of SafeSquid.
Open Reports → Detailed logs; look for filter_name related to cookies and native cookie: lines when COOKIE is enabled in LOG_LEVEL.
Check debug response header X-Cookie-Filter on the connection (Dropped-Cookie-Out when cookies were stripped).
Enable Trace Entry on one row to confirm profile and domain matching in Native logs.
The Header-filtering section (safesquid-header-filtering(5)) allows administrators to strip out or inject HTTP headers into client requests or server responses.
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).
Profiles — Apply only when the connection has one of these profiles. Blank = all connections. Prefix ! to skip connections that have a profile (for example !Guest).
Type — On Allow/Deny: regex on the header field name (for example Referer, User-Agent); blank matches any name. On Insert: literal header name to add (not a regex).
Value — On Allow/Deny: regex on the field value; blank matches any value. On Insert: header body with variables expanded.
Applies to — CLIENT HEADER — request headers (browser → origin). SERVER HEADER — response headers (origin → browser). Row must include the direction being filtered.
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.
Use View headers in the Web UI to capture real header names and values before writing regexes.
Enable HEADER in LOG_LEVEL and read native removed: / added: lines.
Open Reports → Detailed logs while reproducing from a known client.
Enable System configuration debug response headers (see Debug response headers) to inspect policy outcomes on the wire.
The Elevated section reduces cross-site tracking by stripping third-party cookies and selected tracking headers. Without it, third-party cookies and related trackers can follow users from site to site.
On each request and response header pass, enabled Elevated policy rows are walked top to bottom. The first matching row sets the privacy level for that connection; later rows are skipped.
NOT-REQUIRED — No stripping; bypass elevated privacy.
LOW — Drop third-party Cookie and Set-Cookie when cookie flag set.
STANDARD — LOW plus remove Referer and Origin on outgoing requests.
PARANOID — STANDARD plus remove User-Agent (may break browser-variant sites).
Changes are logged to the privacy log and Detailed logs with filter name Elevated-Privacy. Debug header X-Elevated-Privacy reports level when Send Debugging Headers includes client.
Open Configure → Restriction Policies → Privacy control → Elevated Privacy → Elevated
policies. Rows are tested top to bottom; the first enabled match sets the level for the
connection.
