Modern web pages are not built exclusively from an organization's own JavaScript. Payment pages, analytics tools, chat widgets, A/B testing systems, ad tags and payment SDKs can each load multiple third-party scripts. If any one of those scripts is compromised, malicious code running in the user's browser can bypass a WAAP's classic request-level controls entirely.
In payment flows in particular, client-side risk is no longer just a best-practice matter. PCI DSS 4.0 v4.0.1 has made the control, inventory and integrity of scripts running on payment pages more visible. Organizations must be able to demonstrate which sources are permitted to execute on which pages.
Asking application teams to add CSP, HSTS, frame protection and referrer policy headers manually to every page is not sustainable. Code changes are difficult in legacy applications; in modern applications, different service teams may not consistently apply the same security standard. The result is security headers present on some pages and absent on others.
The right approach is to enforce browser security headers centrally, independently of application code and from a policy-driven position. The ADC should rewrite response headers to standardize CSP, HSTS, clickjacking protection, MIME-sniffing prevention, referrer control and fingerprint cleanup.
TR7 Client-Side Script Protection delivers this model: it applies foundational security headers for client-side risk at the vService level and ties browser security to the central WAAP policy.
TR7 implements client-side script protection through response header rewriting, a CSP profile, fingerprint cleanup and compliance visibility.
TR7 applies security headers during the HTTP response phase using set-header or add-header behavior. Browser security controls can be activated without changing application code or the certificate structure.
The Content-Security-Policy header communicates the permitted source model to the browser. TR7 currently provides baseline CSP protection through a fixed `default-src 'self';` approach.
Headers such as Server, X-Powered-By, X-AspNet-Version and X-AspNetMvc-Version can be stripped from responses. This makes it harder for attackers to build a technology inventory and match CVEs.
vServices with an active securityHeaders rule can be surfaced as evidence in compliance reports. This strengthens the audit trail for payment page security and client-side control processes.
Client-Side Script Protection applies 8 ready-made security headers under a single securityHeaders rule.
TR7 can add the Content-Security-Policy header through the securityHeaders rule. The current behavior produces a baseline security policy with `default-src 'self';`. This policy targets a browser default that only accepts resources from the same origin. More complex CSP requirements should be addressed through custom header configuration or application-side changes.
The Strict-Transport-Security header can be applied on TLS connections. It instructs the browser to require HTTPS for the relevant domain. Options such as includeSubDomains and preload provide stricter security behavior. HSTS is applied only in TLS context to prevent incorrect policy being issued to HTTP-only hosts.
The X-Frame-Options header can be applied with the SAMEORIGIN value. This restricts the page from being loaded inside an iframe on a different origin. It helps reduce clickjacking risk particularly on login, payment, admin panel and sensitive transaction pages. It provides low-cost baseline protection against user interface redress attacks.
The X-Content-Type-Options header can be added with the nosniff value. This helps prevent the browser from guessing a content type and executing content in an unexpected format. The control is especially valuable for file upload flows, static content and legacy applications that return incorrect content types. Client-side risk from MIME confusion is reduced.
The Referrer-Policy header can be applied with a no-referrer-when-downgrade default. This limits referrer leakage in scenarios such as transitions from HTTPS to HTTP. Referrer behavior matters on URLs that carry citizen, customer or session parameters. Organizations can centrally limit how much source URL information the browser carries to external sites.
The Permission-Policy header can be used to restrict access to browser capabilities such as the microphone, camera, geolocation and similar APIs. TR7 applies this header under the securityHeaders rule to reduce unnecessary browser permission surface. On portal, payment and admin screens in particular, this prevents pages from accessing unexpected APIs. Client-side security is not limited to script origin alone.
Although the X-XSS-Protection header has limited effect in modern browsers, it can be used for compatibility with older clients. The `1; mode=block` behavior activates a basic XSS filter in some legacy browsers. This header is not a security guarantee on its own and should be considered alongside CSP and WAAP controls. It provides a low-cost additional layer for organizations with a legacy user base.
TR7 can remove headers such as Server, X-Powered-By, X-AspNet-Version and X-AspNetMvc-Version. These headers can hint at the application server, framework or runtime version in use. Attackers can use this information for CVE matching and targeted exploit attempts. Fingerprint cleanup is a practical hardening step that reduces visible attack surface.
securityHeaders can be bound as a rule type to specific vService, domain or path conditions. A payment page can run with a stricter set, an internal portal with a different one, and a legacy application with a more permissive combination. This prevents a single global header policy from breaking applications. Operators apply security headers according to service context.
TR7 implements the current scope of client-side script protection at the response header layer. No additional JavaScript agent, client SDK or separate reverse proxy is needed. This approach provides low latency and broad compatibility. The actual current capability is security header standardization; no claim is made for runtime skimmer detection or automatic SRI injection.
vServices with an active securityHeaders rule can be surfaced in compliance reports. This makes it easier to share with auditors exactly where payment page security headers are applied. It supports the production of technical evidence for client-side security expectations under PCI DSS 4.0 v4.0.1. Reporting makes visible not just that a header policy is configured, but on which services it is active.
When custom HTML pages are returned — such as for bot protection or access blocking — security headers can be maintained on the same response path. This prevents error or challenge pages from returning with weaker security headers than the main application. Every response presented to the user approaches the same baseline browser security standard. Consistency is especially important in login and bot verification flows.
Client-side script protection operates across response header ordering, the HSTS condition, fixed CSP behavior, the securityHeaders rule type and fingerprint cleanup.
TR7 can override some headers with set-header and add others with add-header. This distinction determines how existing application headers behave. Before going to production, it is worth testing whether the application's own headers conflict with those added by TR7.
HSTS should only be applied on TLS connections. TR7 associates this header with the ssl_fc condition to prevent HTTP-only hosts from receiving a spurious HSTS header. Incorrect HSTS policy can cause access problems on some domains, so it should be used with care.
When CSP is enabled in the current securityHeaders behavior, the `default-src 'self';` header is produced as a fixed value. There is no additional custom directive editor within the active capabilities of this page. For more detailed CSP requirements, a custom header rule or application-side configuration should be planned.
securityHeaders does not work like a WAAP signature scoring rule. It is treated as a response header hardening rule that is always applied. As a result, it is not bound to an attack score or threshold outcome.
The Server, X-Powered-By, X-AspNet-Version and X-AspNetMvc-Version headers can be removed. Removing these headers does not change application behavior; it only reduces the visibility of technology information externally. In legacy applications, this simple step can meaningfully reduce information leakage.
CSP and frame policies can affect some application components. Pages that use inline scripts or load content from external sources in particular should be validated in a test environment first. TR7's rule-based approach makes it straightforward to trial a strict policy on a limited path or domain before rolling it out broadly.
E-commerce teams can enable CSP, HSTS and server fingerprint cleanup at the vService level on checkout pages. This setup produces reportable technical evidence for PCI DSS 4.0 v4.0.1 client-side security controls.
Banking portals can use X-Frame-Options SAMEORIGIN and Permission-Policy to restrict unauthorized iframe embedding and unnecessary browser API access. Client-side attack surface on login and transaction pages is narrowed.
Public-sector applications can apply Referrer-Policy on pages carrying sensitive URL information. This reduces the risk of URL fragments tied to citizen sessions or transaction context being carried to external sites.
In older .NET or similar applications, Server, X-Powered-By and framework version headers can leak externally. TR7 removes these headers, making it harder for attackers to build a technology inventory.
SaaS providers can apply different securityHeaders combinations for each tenant vService. B2B tenants can run a more permissive policy where compliance requirements allow; B2C flows can use a stricter header set.
CSP, HSTS, clickjacking protection and server fingerprint cleanup — from a single policy, without touching application code. Let us walk you through a live setup on your own services.