Security Headers
Automatically inject HTTP security headers on every proxied response — with one-click presets for Standard and Strict profiles.
Security Headers lets you inject a set of HTTP security headers into every response served through the SerpWise gateway for your domain. These headers tell browsers how to handle your content — enforcing HTTPS, preventing clickjacking, controlling referrer data, and restricting access to browser APIs — without touching your server configuration.
Security Headers are configured from the Security Headers tab in your domain dashboard.
Quick Setup Presets
Instead of typing header values manually, use the Quick setup presets at the top of the form to populate all fields at once. You can then adjust individual values before saving.
| Standard | Strict | |
|---|---|---|
| Best for | Most websites — ecommerce, blogs, marketing | High-security apps that need maximum protection |
| Caveat | — | CSP may need tuning for third-party scripts |
Clicking a preset fills all header fields but does not save automatically. Review the populated values and click Save Security Headers to apply.
Header Reference
Strict-Transport-Security (HSTS)
Forces browsers to connect over HTTPS for the specified duration. Once a browser has seen this header, it will refuse HTTP connections to your domain for the max-age period.
| Preset | Value |
|---|---|
| Standard | max-age=31536000; includeSubDomains |
| Strict | max-age=63072000; includeSubDomains; preload |
max-age— how long (in seconds) browsers remember to use HTTPS. Standard = 1 year, Strict = 2 years.includeSubDomains— applies the rule to all subdomains.preload(Strict only) — signals intent to be included in browser HSTS preload lists. Requires submitting your domain to hstspreload.org.
The preload directive is a long-term commitment. Once submitted to preload lists, removing HSTS requires months of propagation. Only use Strict if you're confident your domain will always serve HTTPS.
Content-Security-Policy (CSP)
CSP now has a dedicated CSP Builder with structured per-directive controls, report-only mode, violation reports, and auto-detection of external sources. See the full Content Security Policy documentation.
The raw CSP string field in Security Headers still works, but the structured CSP Builder takes precedence when both are configured. We recommend using the CSP Builder for new setups.
X-Frame-Options
Prevents your pages from being embedded in iframes on other domains, protecting against clickjacking attacks.
| Preset | Value |
|---|---|
| Standard | SAMEORIGIN — allows embedding by pages on your own domain |
| Strict | DENY — blocks all iframe embedding, including from your own domain |
Use SAMEORIGIN if you embed your own pages in iframes (e.g. a checkout widget). Use DENY if you never embed your own content.
X-Content-Type-Options
Prevents browsers from guessing (MIME-sniffing) the content type of a response and treating it differently from what the server declares.
| Preset | Value |
|---|---|
| Standard | nosniff |
| Strict | nosniff |
This is a safe header to set on all sites. nosniff is the only valid value.
Referrer-Policy
Controls how much information about the referring URL is sent when a visitor navigates away from your site or when a resource request is made to another origin.
| Preset | Value |
|---|---|
| Standard | strict-origin-when-cross-origin |
| Strict | strict-origin |
strict-origin-when-cross-origin(Standard) — sends full URL when navigating within your domain; sends only the origin (no path) on cross-origin requests. Good for SEO — referrer data still flows to your analytics, but paths aren't exposed to third parties.strict-origin(Strict) — sends only the origin on all requests (same-origin and cross-origin). Use this if you don't want URL paths exposed in any referrer header.
Permissions-Policy
Restricts which browser APIs and hardware features (camera, microphone, geolocation, etc.) your page and embedded iframes are allowed to access.
| Preset | Value |
|---|---|
| Standard | camera=(), microphone=(), geolocation=() |
| Strict | camera=(), microphone=(), geolocation=(), payment=(), usb=() |
An empty value () means "disabled for all origins including this page." Extend the policy if your site legitimately uses these features — for example, a store using the Payment Request API should remove payment=().
Cross-Origin-Opener-Policy (COOP)
Controls whether your page can share a browsing context group (process) with cross-origin popups. This is primarily relevant for protecting against cross-origin information leaks and enabling features like SharedArrayBuffer.
| Preset | Value |
|---|---|
| Standard | same-origin-allow-popups |
| Strict | same-origin |
same-origin-allow-popups(Standard) — your page is isolated from cross-origin pages, but your page can open popups (e.g. OAuth flows, payment popups) that retain access to the opener. Recommended for most sites with OAuth or payment flows.same-origin(Strict) — full isolation. Your page cannot communicate with any cross-origin popup, including OAuth windows. Use with caution if your login or payment flow opens a popup.
Cross-Origin-Resource-Policy (CORP)
Controls which origins can load your resources (images, scripts, fonts) using fetch() or <img>, preventing cross-origin information leaks.
| Preset | Value |
|---|---|
| Standard | same-site |
| Strict | same-origin |
same-site(Standard) — resources can be loaded by pages on the same site (includes subdomains). Use this if resources are served from a CDN subdomain.same-origin(Strict) — resources can only be loaded by pages on the exact same origin. Use this for maximum resource isolation.
How It Works
Security headers are injected after your origin response is received and after rule processing. The injection order is:
- Origin server returns its response headers
- SerpWise rules engine runs (rules can add/remove headers via
set_response_header/remove_response_header) - Security Headers are injected — rules take precedence over Security Header values for any header set by both
This means you can use Security Headers to set global baseline headers and use individual rules to override specific headers on specific pages.
If your origin already sets one of these headers, SerpWise will overwrite the origin's value with your configured value. If you want to preserve your origin's header value for a specific header, leave that field blank in the Security Headers form.
Enabling Security Headers
- Navigate to your domain in the dashboard
- Click the Security Headers tab
- Toggle Enable Security Headers on
- Click Standard or Strict to pre-populate all fields, or enter values manually
- Review or adjust individual fields as needed
- Click Save Security Headers
Changes take effect on the next proxied request — no deployment required.
Relationship to Shield
Security Headers and Shield are separate features, each with their own tab:
- Shield — blocks exploit path attempts, auto-bans malicious IPs, and enforces rate limiting
- Security Headers — injects HTTP headers on every response to protect visitors' browsers
They can be enabled independently or together.
Relationship to Rules
For per-page or conditional header control, use the set_response_header and remove_response_header rule actions instead of or in addition to Security Headers.
Example: Enable Security Headers globally for HSTS, CORP, and COOP, then use a rule to set a stricter CSP on /checkout/* pages.
Limitations
- Empty fields are skipped — if you leave a header field blank, that header is not injected. This is intentional: leave CSP blank if you haven't defined your policy yet.
- No per-page control — Security Headers applies to every response for your domain. For conditional header injection, use rule actions. For CSP specifically, use report-only mode to test before enforcing.
- Overwrites origin headers — headers you configure here replace any same-named header from your origin server.
SerpWise Shield
Edge security features that block exploit attempts, auto-ban malicious IPs, and rate limit abusive traffic — without server configuration.
Content Security Policy
Build, test, and enforce a Content Security Policy with the structured CSP Builder — including report-only mode, violation reports, and automatic source detection.