Security headers explained: what each one does

このコンテンツは英語です。

Every time a browser loads a page, the server sends a set of invisible instructions called HTTP headers. Some of them tell the browser how to handle the page, and a handful are dedicated to protection. Security headers tell the browser to refuse certain risky behaviour, such as loading scripts from unexpected places or framing your page inside someone else's site. This guide explains the six headers you are most likely to meet, what each one does, a simple worked example and how to check your own site with the security headers tool on Valtrinity.

Valtrinity 編。更新日：2026年10月18日。

What security headers are and why they matter

Headers are sent with each response, before the page itself. A security header is simply one of these instructions with a protective purpose. The browser reads it and changes its behaviour. A header cannot fix a bug in your code, but it can limit the damage a bug or a third-party problem might cause, and it can stop some common attacks from working as easily.

Headers are easy to forget because they live on the server rather than in the page. A site can look perfectly normal while sending none of them. Checking them is a quick way to find out what the browser is being told.

• Headers are instructions the browser follows.
• They limit damage; they do not fix bugs.
• They are easy to forget because they are not visible on the page.

Strict-Transport-Security

Strict-Transport-Security, often shortened to HSTS, tells the browser that this site must only be reached over HTTPS for a set period. Once the browser has seen the header, it will switch plain HTTP addresses to HTTPS itself, without waiting for the server to redirect. The max-age value sets how long this memory lasts, in seconds.

Be careful with HSTS. If you enable it and later find that some part of the site cannot serve HTTPS, visitors may be stuck. Make sure the whole domain and every subdomain is ready before you enable the includeSubDomains option.

• Example value: max-age=31536000; includeSubDomains.
• Only enable it once HTTPS works everywhere on the domain.

Content-Security-Policy

Content-Security-Policy is the most powerful and the most fiddly of the six. It lists the places that scripts, styles, images, fonts and frames may be loaded from. If a page tries to load a script from a source that is not listed, the browser blocks it. This stops many injection attacks, where an attacker tries to slip their own code into a page.

Writing a policy takes care. A strict policy can break a site that relies on analytics, chat widgets or fonts, so start with a report-only policy, check what would be blocked, and only then enforce it.

• Lists allowed sources for scripts, styles, images and frames.
• Blocks anything loaded from an unlisted source.
• Test in report-only mode before enforcing it.

X-Content-Type-Options

Browsers sometimes try to guess the type of a file from its contents rather than its declared type. This is called MIME sniffing, and attackers can exploit it by disguising a script as an image. The header X-Content-Type-Options with the value nosniff tells the browser to trust the declared type and not guess.

This is one of the simplest headers to add, and it rarely causes problems. If a file is served with the wrong content type, nosniff may stop it from running, which is usually a sign that the server configuration needs fixing.

• Value: nosniff.
• Rarely causes problems; wrong content types will show up.

X-Frame-Options

Framing happens when another website places your page inside an iframe. Attackers use this for clickjacking, where a visitor thinks they are clicking one thing but is actually clicking a hidden button on your page. X-Frame-Options can be set to DENY, which blocks all framing, or SAMEORIGIN, which allows your own site to frame itself.

Newer browsers also support the frame-ancestors directive inside Content-Security-Policy, which does the same job with more options. Many sites set both, so older browsers are still covered.

• DENY: no framing anywhere.
• SAMEORIGIN: only your own site may frame your pages.
• frame-ancestors in Content-Security-Policy does a similar job.

Referrer-Policy

When a visitor clicks a link from your page to another site, the browser usually sends the full address of the page they came from. That address can contain personal details in its path or query string. Referrer-Policy controls how much of that address is shared. A value such as strict-origin-when-cross-origin sends only the domain when the request goes to another site, and the full address only within your own site.

• strict-origin-when-cross-origin is a common, sensible value.
• It limits what other sites learn about the page a visitor came from.

Permissions-Policy

Permissions-Policy, formerly called Feature-Policy, controls which browser features the page and any embedded frames may use. Features include the camera, microphone, location and payment request. If your page never uses the camera, you can tell the browser to block it entirely. That way, even if a third-party script were compromised, it could not ask for camera access through your page.

Worked example. A brochure site with a contact form has no need for location or the camera. A header such as camera=(), microphone=(), geolocation=() turns those features off. Visitors lose nothing they would have used, and the browser has one less thing to worry about.

• Turn off features you never use.
• Example: camera=(), microphone=(), geolocation=().

Check your headers with the security headers tool

Open the security headers tool on Valtrinity and enter your web address. The result lists each header, whether it is present and what value the server sends. Use it after every change to your hosting or server settings, because a new configuration can quietly drop headers that were working before.

Do not aim for a perfect score at once. Add the simple headers first, such as nosniff and Referrer-Policy, then add HSTS once HTTPS is fully working, and leave Content-Security-Policy until you have tested it in report-only mode.

• Start with nosniff and Referrer-Policy.
• Add HSTS once HTTPS works on every subdomain.
• Roll out Content-Security-Policy carefully.

このガイドで紹介したツール

よくあるご質問