Skip to content 
I show specifically which security headers really count for web servers and how I reliably implement them on Apache, Nginx, IIS and WordPress - including tests, examples and pitfalls. I use the focus keyword security header webhosting into practice and increase browser security without major changes to the application.
Key points
- HSTSForce HTTPS and stop downgrade attacks
- CSP: Whitelisting sources and reducing XSS risks
- X-Frame: Prevent clickjacking and control embedding
- nosniffPrevent MIME sniffing and secure types
- Referrer: Limit disclosure of sensitive information
What security headers do
Security headers are small but very effective HTTP-instructions, which the browser strictly observes. I use them to control the loading of resources, block insecure embeddings and intercept faulty file types [1][3]. Especially against XSS, clickjacking and session leaks, these specifications build strong Barriers on. Without these rules, the browser allows too much, which attackers can exploit. I consciously plan the headers, test changes step by step and check whether application functions continue to work as expected. work.
I combine security headers with TLS, logging and patch management because these components are mutually reinforcing. supplement. HSTS enforces HTTPS, CSP controls sources, X-Frame-Options prevents unwanted iFrames. In addition, X-Content-Type-Options slows down sniffing and Referrer-Policy reduces metadata for outgoing Inquiries. Modern browsers implement some of the protection mechanisms natively, but clear server instructions remain important [5]. This is how I keep the risk low and reduce attack surfaces to Protocol-level.
In practice, I also take caching and proxy layers into account: Reverse proxies, CDNs or application firewalls can overwrite or remove headers. I document the responsibility per layer and verify at the browser edge what actually arrives. For security-critical specifications, I set headers on the last instance before the Internet and ensure that downstream systems do not change them.
The most important headers at a glance
Before I build the configuration, I make sure I have a clear Overview on purpose, example value and risk coverage. I use the following table as a compact cheat sheet for planning and review.
| Header | Purpose | Example | Risk coverage |
|---|---|---|---|
| Strict Transportation Security (HSTS) | Force HTTPS | max-age=63072000; includeSubDomains; preload | Downgrade, MITM [3][5] |
| Content Security Policy (CSP) | Whitelist sources | default-src 'self'; script-src 'self' https://cdn.example | XSS, data injection [3][2] |
| X-Frame-Options | Regulating embedding | SAMEORIGIN | DENY | Clickjacking |
| X-Content-Type-Options | Stop MIME sniffing | nosniff | Type confusion [5][2] |
| Referrer policy | Limit referrer data | strict-origin-when-cross-origin | Data outflow [5][2] |
HSTS briefly explained
With HSTS I force the browser permanently to HTTPS and prevent downgrades. The header contains values such as max-age, includeSubDomains and optionally preload for inclusion in the preload list [3][5]. I only set HSTS after clean TLS forwarding, a valid certificate and a check of all subdomains. If you want to go deeper, you can find specific steps at Activate HSTS. This is how I close gaps in the first connection and block insecure Requests.
CSP: Fine granular control
I use CSP to specify the sources from which the browser may load scripts, styles, images and frames. I start tightly with default-src 'self' and specifically allow additional domains per directive. A rule that is too hard can stop features, so I test changes with report-only first. For a structured introduction, I use a clear plan, starting with script-src and style-src, for example. This way I reduce XSS sustainably and keep third-party sources under Control [3][2].
Further modules
I block clickjacking with X-Frame-options and prevent sniffing with X-Content-Type-Options: nosniff. I also set the referrer policy to strict-origin-when-cross-origin to avoid leaks. For APIs, I check CORS so that Access-Control-Allow-Origin is set correctly. For authorizations, I rely on permissions policy instead of feature policy in order to finely limit device access. This keeps the interface clear and the client side follows Rules.
Important: For modern setups, I replace X-Frame-Options with frame-ancestors in the CSP. This directive is more flexible and is preferred by current browsers. If both are running in parallel frame-ancestors define the desired embedding logic; X-Frame-Options then serves more as a safety net for older clients.
Extended headers: COOP/COEP, CORP and Permissions-Policy
I use additional headers for isolated browser contexts. With Cross-Origin-Opener-Policy (COOP) I separate window/tab contexts from foreign origins, typical value: same-origin. Cross-Origin-Embedder-Policy (COEP) requires that embedded resources are explicitly released (require-corp). In combination with Cross-Origin Resource Policy (CORP) I can clearly control sharing and lay the foundation for isolated realms (e.g. SharedArrayBuffer).
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-site
Permissions-Policy: geolocation=(), microphone=(), camera=(), payment=(), interest-cohort=()The Permissions policy restricts device access and features that a page may request. I set restrictive defaults and only allow what is actually used. It is important to review the integrations (e.g. payment or card providers) in order to specifically allow necessary exceptions - never across the board.
Apache: Security header in .htaccess
On Apache I set headers directly in the .htaccess or in the VirtualHost configuration. Before making changes, I save the file and document each step for later reviews [2][4][6]. After saving, I check the delivery in the browser network tab and validate values with analysis tools. Caution with caching: Some proxies overwrite fields, so I check intermediate layers. Only after a stable test run do I increase max-age, activate includeSubDomains and think about preload to.
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header set Content-Security-Policy "default-src 'self'"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header set X-XSS-Protection "1; mode=block"
Header set Referrer-Policy "strict-origin-when-cross-origin"
I keep values consistent across Subdomainsso that different answers don't cause confusion. With WordPress on Apache, I move the header rules into the .htaccess before the WP block markers. This way, the server manages the defaults, regardless of the active theme. For CSP, I often run Report-Only first in order to cleanly record permitted sources. Then I switch to Enforce and increase the Rigor step by step.
For 3xx/4xx/5xx responses I prefer to use Apache Header always setso that the headers also reach redirects and error pages:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
# Set CSP specifically for HTML responses:
Header set Content-Security-Policy "default-src 'self'"
Nginx: Header in the server block
Under Nginx, I create the headers in the appropriate server-block of nginx.conf or a site file. After each change, I reload the configuration and check the error log. For HTTPS, I first set up redirects correctly so that HSTS takes effect immediately and no mixed states occur. If you implement the forwarding correctly, you will avoid many subsequent problems - instructions are provided Set up HTTPS forwarding. Then I activate headers line by line, test the page and check the Answers.
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
add_header Content-Security-Policy "default-src 'self'";
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";
add_header Referrer-Policy "strict-origin-when-cross-origin";
I check whether Nginx is displaying the headers in all Locations also for static files and caching paths. For CSP with external CDNs, I add script-src and style-src specifically. I disarm inline scripts with nonces or hashes instead of 'unsafe-inline'. Where possible, I remove eval-like constructs so that script-src 'self' remains realistic in the long term. This reduces the XSS risk and improves the security score in the Audit.
I pay attention to this with Nginx, add_header ... always so that headers are also sent with 301/302/304/4xx/5xx. I also set headers contextually: CSP only for HTML, not for images or downloads. I reduce this with location-scopes.
location / {
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'self'" always;
}
location ~* .(css|js|png|jpg|svg|woff2?)$ {
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}
IIS and WordPress: Set headers cleanly
On Windows servers, I enter the headers in the web.config and restart the application pool. The structure with is clear and can be managed well with version control [1]. With WordPress, I have three options: .htaccess (Apache), a security plugin or PHP via functions.php. I prefer the server level because it remains independent of the theme and offers less attack surface [4][2]. For CSP details, I like to use a compact CSP Guide as a reference in the project repo.
In WordPress setups, I pay attention to possible Conflicts between plugin headers and server headers. I solve double delivery by setting headers in only one place. For CSP rules with many external services, I keep a list of permitted domains in the documentation. This keeps changes traceable and the review simple. This reduces maintenance effort and prevents unexpected Blockages.
Practical tip: Frontend and /wp-admin have different needs. I isolate CSP rules so that the block editor (inline styles, inline scripts) is not unnecessarily restricted. For AJAX endpoints (admin-ajax.php) and REST API, I test CORS and CSP separately. Where only modern browsers are supported, I can X-XSS protection can be omitted - newer browsers ignore the header anyway; for legacy clients I leave it as it does no harm.
Reverse proxy, CDN and caching
In multi-level architectures, I clearly define which layer Source of truth for security headers. If a CDN is running in front of it, I prefer to configure headers there or make sure that the CDN passes on the Origin headers 1:1. I avoid contradictory setups in which CDN and Origin set the same header differently.
Caching rules are also important: Headers must not be lost in 304 responses. I check whether the platform delivers headers for conditional requests. For CORS content, I set the necessary Vary-header (e.g. Vary: Origin) so that proxies do not deliver incorrect responses. For static CDN assets, I set security headers where the files are actually served (e.g. object storage/CDN edge).
Testing and monitoring the headers
After implementation, I check the output of each Headers in the network tab of the developer tools. I verify values, check redirect chains and simulate scenarios with and without login. I also validate whether subdomains deliver the same specifications and whether caches are not playing old variants. With CSP, I monitor the block and report events in order to identify missing sources and release them in a targeted manner. This discipline prevents failures and demonstrably maintains the protective effect. high [2][4][6].
I specifically test mixed content, embedded widgets and payment workflows because these are often where Error occur. For iFrames, I check whether SAMEORIGIN or explicit permissions are sufficient. Report-Only helps me to make rule changes visible without immediate blocking. For CI/CD, I integrate header checks into automated pipelines. This allows me to detect deviations early on and keep the configuration uniform.
For quick validation I use curl and inspect the response headers directly in the shell:
curl -sI https://example.com | grep -Ei "strict-transport|content-security|x-frame|x-content|referrer-policy"
curl -sI -H "Accept: text/html" https://example.com/path/
curl -sI https://sub.example.com | grep -Ei "strict-transport"
With CSP reports, I evaluate the events centrally. I start small (e.g. script-src only) and expand the policy if the noise in the reports remains low. In CI/CD, I check random samples of HTML, CSS, JS and API endpoints so that no response classes are forgotten.
Common faults and maintenance
CSP rules that are too restrictive block legitimate Features and cause tickets - that's why I proceed step by step. Missing HTTPS forwarding weakens HSTS and creates inconsistent experiences. Duplicate headers from the app and proxy generate contradictory values, which I consolidate cleanly. During preload, the domain must be completely ready, otherwise I unintentionally lock out subdomains [3][5]. Scheduled reviews keep the configuration fresh and adjust values to new Browser-versions.
I keep a short documentation with responsibilities so that changes are transparent and testable remain. Version control of server configurations helps with rollbacks. I define clear steps for emergencies, such as deactivating individual rules and then analyzing the cause. This allows me to react quickly without losing the entire protection. This saves time and reduces Risks in operation.
Other practical stumbling blocks: The total length of the headers should respect the limits of proxies (some systems limit headers to a few KB). CSP directives require exact Syntax (semicolons, quotation marks, correct keywords). With SRI (Subresource Integrity), I supplement external scripts/styles with integrity hashes to detect manipulation - in combination with a restrictive CSP, the risk is significantly reduced. Finally, I make sure that meta tags (e.g. ) none are replacements for security-critical headers such as HSTS or CSP.
CSP step-by-step with report-only
I often start CSP with a Report-Only phase so that I can see real violations without blocking users. First I set default-src 'self' and gradually add script-src and style-src. For inline code, I set nonces or hashes to avoid 'unsafe-inline'. I then activate the rules, continue to monitor messages and remove old exceptions. In this way, the strictness grows in a controlled manner while the application remains functional. remains [3][2].
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-to default-endpoint
Optionally, I define a reporting endpoint structure via the Reporting API to collect CSP violations and network errors in an organized manner. This allows me to recognize trends and evaluate exceptions quickly.
Report-To: {"group": "default-endpoint", "max_age":10886400, "endpoints":[{"url": "https://reports.example.com/csp"}]}
NEL: {"report_to":"default-endpoint","max_age":10886400,"success_fraction":0.0,"failure_fraction":1.0}
For complex projects, I maintain a Whitelist matrix by function group (Payments, Analytics, Maps, Video) and display these in CSP in an organized manner. I plan my own guidelines for the admin area or microsites if their integrations differ. This keeps the CSP clear and easy to maintain.
HSTS, preload and first delivery
Before I activate HSTS with preload, I make sure that each subdomain HTTPS is supported. I set up redirects properly, check mixed content and check certificates. Only then do I increase max-age to several months or years and submit the domain for preload if necessary [3][5]. If you act hastily here, you will block legitimate traffic or generate support costs. With an organized plan, the changeover remains safe and comprehensible.
For development and staging environments, I use lower max-age-values. This allows me to correct problems more quickly without long waiting times. In productive environments, I keep the values permanently high. I monitor metrics and complaint channels in the first few days after activation. This allows me to recognize side effects early and react fast.
In practice, it has proven to be a good idea to activate HSTS initially without preload, observe redirects and certificates for a few weeks and only check preload after a stable phase. For large domain landscapes, I document the changeover for each subdomain and plan a fallback strategy if a service is not yet fully HTTPS-capable.
Quick check questions for admins
I first clarify whether each Domain cleanly to HTTPS and whether certificates are up to date. I then check whether HSTS, CSP, X-Frame-Options, X-Content-Type-Options and Referrer-Policy are rolling out correctly. I validate responses for HTML, CSS, JS, images and APIs so that no paths are missing. I document approvals for CDNs and keep the list up to date. Finally, I secure the configuration, schedule a review date and test the Reports.
Additional practice details: cookies, admin areas, downloads
Even if cookie flags are not classic security headers, I pay attention to their setting in the Set cookie-headers: Secure, HttpOnly and SameSite noticeably reduce the risk of session cookies. For file downloads, I verify that CSP does not block unexpectedly and that the MIME types are delivered correctly (leave nosniff active). If necessary, I encapsulate admin areas with more restrictive guidelines, in particular stricter frame-ancestors and narrower script sources.
Summary
With a few clear headers, I increase the Security of every web application. HSTS protects the transport layer, CSP controls content, X-Frame-Options slows down clickjacking, nosniff fixes types and Referrer-Policy reduces data outflow. I implement the rules cleanly for each server environment, test thoroughly and document decisions. In this way, I minimize risks without losing functionality [1][3][5]. Those who use security headers in a targeted manner increase trust, meet compliance requirements and present a professional image. Web presence.
