HTTP Security
TrustGate includes a built-in HTTP Security that enforces security-related HTTP headers and validates incoming requests based on allowed hosts, HTTPS requirements, and security header policies. This middleware provides defense-in-depth protections against common web-based attacks such as clickjacking, MIME-sniffing, insecure transport, and reflected XSS.
It is executed on every incoming request and is configured via the security_config
block in each gateway’s definition.
Features
This feature includes the following security controls:
- Host allowlisting with optional regular expressions.
- SSL enforcement, including redirection to HTTPS and support for reverse proxy headers.
- Strict-Transport-Security (HSTS) support.
- Clickjacking prevention via
X-Frame-Options
. - MIME-type sniffing protection via
X-Content-Type-Options
. - XSS protection headers with
X-XSS-Protection
. - Referrer policy enforcement.
- Content Security Policy (CSP) enforcement.
Configuration Example
What This Configuration Does
allowed_hosts
Accepts requests only from hostnames that match values defined in the allowed_hosts
list. When allowed_hosts_are_regex
is set to true
, each entry is treated as a regular expression. This allows for flexible definitions like "^.*\\.example\\.com$"
to match any subdomain under example.com
. Requests from hosts not matching any pattern are rejected with a 403 Forbidden
.
Use case: Restrict gateway access to only trusted domains and subdomains.
ssl_redirect
Controls whether incoming HTTP requests should be automatically redirected to HTTPS. If set to true
, TrustGate issues a 301 Moved Permanently
response, redirecting the client to the secure ssl_host
. This ensures all traffic is encrypted.
In this configuration, it is set to false
, so insecure requests are accepted without redirection.
Use case: Enforce secure connections, especially in production environments without upstream TLS termination.
ssl_proxy_headers
Defines trusted HTTP headers that indicate the request was originally made over HTTPS, typically used when TrustGate is behind a TLS-terminating reverse proxy or load balancer. For example, X-Forwarded-Proto: https
.
Use case: Accurately detect HTTPS even when TLS is terminated upstream.
sts_seconds
Specifies how long (in seconds) the browser should enforce HTTPS-only communication for this site using the Strict-Transport-Security
header. A value of 31536000
instructs browsers to remember the rule for one year. Combined with sts_include_subdomains
, this applies the rule to all subdomains as well.
Use case: Harden transport security by eliminating the possibility of protocol downgrade attacks.
frame_deny
Enables the X-Frame-Options: DENY
response header, preventing the site from being embedded in an iframe. This mitigates clickjacking attacks, where an attacker tricks users into clicking something different than what they perceive.
If custom_frame_options_value
is provided, it will override the default.
Use case: Prevent other sites from embedding TrustGate responses.
referrer_policy
Defines how much referrer information should be included in requests sent from the browser. The value strict-origin-when-cross-origin
means full referrer information is sent for same-origin requests, but only the origin is sent for cross-origin requests, and nothing is sent from HTTPS to HTTP.
Use case: Minimize sensitive URL exposure in cross-site requests.
content_security_policy
Sets the Content-Security-Policy
(CSP) header, which limits the sources of scripts, styles, and other content that can be loaded. For example:
This policy allows scripts only from the same origin or a trusted CDN, and completely blocks embedding objects like Flash or Java applets.
Use case: Prevent cross-site scripting (XSS) and data injection by restricting content origins.
content_type_nosniff
When enabled, TrustGate sends the following HTTP header:
This instructs browsers not to attempt MIME-type sniffing and to strictly follow the declared Content-Type
header. It helps prevent situations where a browser might incorrectly interpret the content type, potentially exposing the client to security risks.
Use case: Prevent MIME-type confusion attacks, which can lead to content being executed in unexpected or unsafe ways.
browser_xss_filter
Enables the legacy X-XSS-Protection
header with the value:
This activates built-in cross-site scripting (XSS) protection mechanisms in older web browsers, such as Internet Explorer and early versions of Chrome. When a potential XSS attack is detected, the browser will block rendering of the page.
Use case: Provide basic fallback XSS protection in outdated or legacy environments.
Header Behavior
When properly configured, TrustGate automatically adds the following HTTP headers to secure responses:
Best Practices
-
Use specific host patterns Avoid wildcard regex unless strictly necessary. Specify exact subdomains to tightly control access.
-
Enable SSL redirection Unless behind a trusted TLS termination proxy, redirect HTTP traffic to HTTPS using
ssl_redirect
. -
Set a long HSTS max-age Configure
sts_seconds
to be at least 1 year (e.g.,31536000
) in production environments for strict transport security. -
Use CSP and Referrer Policy Headers like
Content-Security-Policy
andReferrer-Policy
help reduce the browser’s attack surface. -
Disable in development Set
is_development: true
during local development to bypass host and SSL enforcement logic.