Security Headers for a Business Website: A Short Starting Set

Many owners of service websites assume security is someone else’s problem. The site has no customer accounts and no checkout, only pages, a contact form, and a phone number. But a browser only applies several of its built-in protections when the server asks for them, and the server asks through a few lines of text that visitors never see.

Those lines are HTTP security headers: instructions a web server sends with each page that tell the browser how to treat it. Can another site load this page inside a frame? Should the browser refuse plain HTTP from now on? This article draws on the OWASP HTTP Headers Cheat Sheet, Mozilla’s MDN documentation, and two editions of the HTTP Archive’s Web Almanac to set out a short starting set for a business site, and the order in which to turn it on.

---

Why a brochure site still needs them

Most of the protections in this article guard against attacks that rely on the browser doing what an attacker wants rather than what the site intended. A site without logins carries less risk than a bank, but it is not exempt.

What goes wrong when headers are left at defaults

1. Your pages can be framed by anyone. MDN describes clickjacking as an attack in which a decoy site loads the target site in a hidden frame and lines up its own buttons over the real ones, so a visitor’s click lands on the hidden page. Without a framing rule, nothing stops a stranger from placing your inquiry form inside their page.
2. Files can be read as the wrong type. Browsers sometimes guess, or “sniff,” what a file contains. OWASP warns that this guessing can turn a file meant to be inert into one that runs, which matters for any site hosting downloads or user uploads.
3. The server announces its software. OWASP recommends removing the X-Powered-By header. The 2024 Web Almanac found that header on about a quarter of hosts, and the most common values named specific PHP versions.
4. Visitors can be downgraded to plain HTTP. Redirecting from HTTP to HTTPS still leaves the very first request unprotected. HSTS closes that gap on later visits.

---

How response headers work

Every time a browser requests a page, the server replies with the page plus a block of headers. Security headers sit in that block. The browser reads them and adjusts its behavior: it refuses to frame the page, stops guessing file types, or rewrites future http:// links to https://.

Two details catch teams out. First, most of these policies are opt-in. The 2024 Web Almanac notes that policies such as Permissions Policy are “open by default”: no header, no protection. Second, several of them work only as real HTTP headers, not as <meta> tags in the page’s HTML. The 2025 Web Almanac counted 5,564 mobile pages trying to set X-Frame-Options through a <meta> tag, which browsers ignore. MDN notes that the CSP frame-ancestors directive is likewise unsupported in a <meta> element.

That is why header work usually happens in the hosting or server configuration, not in the page template.

---

What the Web Almanac measured

The HTTP Archive runs a large automated crawl of the public web and publishes an annual analysis of it as the Web Almanac. Its Security chapter gives a baseline for how often these headers appear in practice.

Header	2024 Web Almanac (desktop site requests)	Purpose
X-Content-Type-Options	48%	Stops MIME type sniffing
X-Frame-Options	37%	Restricts framing (older mechanism)
Strict-Transport-Security	34%	Forces HTTPS on future visits
Content-Security-Policy	19%	Controls sources, framing, and more
Referrer-Policy	17%	Limits what the previous URL reveals
Permissions-Policy	2.82%	Disables unused browser features

The 2025 edition, published in January 2026, shows the trend continuing. HSTS appeared on 36% of mobile pages, up 6 percentage points, and Content Security Policy adoption rose from 18.5% to 21.9%. Popularity makes a difference: X-Frame-Options was set on 67% of the top 1,000 sites but on only 30% of all sites.

Platform choice matters too. The 2024 chapter found that hosted builders such as Wix and Squarespace send headers such as HSTS and X-Content-Type-Options on nearly all of their sites, while self-hosted systems vary because their creators cannot control how each installation is configured. A custom or self-hosted business site gets these protections only if someone sets them.

“A header that was never sent protects no one. Check the response, not the configuration file.”
— Windware Studio Practice Note

---

A starting set for a business site

The values below follow OWASP’s recommendations, with the framing rule taken from MDN’s clickjacking guidance. They suit a typical site of pages and forms that no partner needs to embed.

Header	Starting value	Notes
X-Content-Type-Options	nosniff	MDN: blocks scripts and stylesheets served with the wrong type. Set correct Content-Type values first.
Content-Security-Policy	frame-ancestors 'self' (or 'none')	MDN calls this the replacement for X-Frame-Options; supporting browsers ignore XFO when both are set.
X-Frame-Options	SAMEORIGIN (or DENY)	Kept as a fallback for older browsers, per MDN’s checklist.
Referrer-Policy	strict-origin-when-cross-origin	Already the modern browser default; OWASP advises stating it explicitly.
Permissions-Policy	camera=(), microphone=(), geolocation=()	Turns off features the site never uses. The 2024 Almanac noted support only in Chromium-based browsers.
X-Powered-By	removed	OWASP: remove all instances.

Two headers on many older checklists should be dropped. OWASP now advises against X-XSS-Protection, warning that it can create cross-site scripting vulnerabilities in otherwise safe sites, and recommends either omitting it or sending 0. It also lists Expect-CT and Public-Key-Pins as headers not to use.

Rolling out HSTS in stages

HSTS deserves its own sequence because it is the one header that can lock visitors out. MDN explains that once a browser has seen it, the browser will not let the visitor click past a certificate error on that domain. OWASP adds the consequence: if the certificate expires or is revoked under a long policy, legitimate visitors may be unable to reach the site until the stored policy runs out.

Chrome’s HSTS preload service (hstspreload.org) recommends ramping up max-age, the number of seconds the browser remembers the rule:

• Confirm every subdomain, including internal ones, works over HTTPS.
• Send max-age=300; includeSubDomains (5 minutes) and check for broken pages.
• Raise to max-age=604800 (1 week), then wait out the full week.
• Raise to max-age=2592000 (1 month), then wait out the full month.
• Move to a long value; the Almanac reports a median max-age of one year.

Preloading is a different decision. Adding the preload directive and submitting the domain puts it on a list built into browsers. OWASP’s example value includes preload, but the preload service itself states that “HSTS preloading is not recommended,” because many browsers already upgrade navigations and the extra benefit is small. It also warns that removal from the list can take months to reach users.

---

Limits and tradeoffs

Headers reduce specific risks. They do not secure a site on their own, and the Almanac chapters make two limits clear.

A full Content Security Policy is hard to get right. Beyond framing, CSP can restrict where scripts, styles, and images load from. OWASP calls it “complex to configure and maintain,” and the 2024 Almanac found unsafe-inline, a keyword that weakens CSP’s script protection, on 91% of desktop sites with a policy. For a site that loads analytics, fonts, a booking widget, and a chat tool, a strict policy is a project with testing. The Content-Security-Policy-Report-Only header, which the Almanac describes as a monitoring mode that reports violations without enforcing them, is the usual way to start.

Hiding versions is not patching. The 2024 chapter notes that removing X-Powered-By does not address the risk of an outdated server. Updates still matter more than headers.

Finally, embedding needs a decision. If a partner legitimately frames one of your pages, such as a booking page shown inside a directory listing, frame-ancestors must name that partner rather than 'none'.

---

Practical takeaways for your next website

1. Check what your site sends today, using browser developer tools or a scanner such as the Mozilla Observatory that OWASP lists.
2. Add the low-risk set first: nosniff, a frame-ancestors rule with an X-Frame-Options fallback, an explicit Referrer-Policy, and no X-Powered-By.
3. Set headers in the server or host configuration, not in <meta> tags, where several are ignored.
4. Ramp up HSTS in stages and keep certificate renewal monitored.
5. Treat preloading and a strict CSP as separate decisions, each with its own testing.

---

Ready to Discuss Your Website?

If you are planning a new website, a service redesign, or custom development for your business, we’re here to help shape the work.

• Explore Our Services: Web Design · Web Development · Website Redesign
• Start a Conversation: Tell us about your project via our Contact Form or email us directly at [email protected].