![\"Four](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/security-header-en.png\")
What the security headers are<\/h2>\n
Four of them carry most of the weight, and each answers a different question.<\/p>\n
Content-Security-Policy<\/strong> lists where the page is allowed to load code from. Anything not on the list is refused by the browser, which is the main defence against injected scripts.<\/p>\n Strict-Transport-Security<\/strong> tells the browser to use the encrypted connection from now on and never the plain one – including when a link, a bookmark or a typed address says otherwise.<\/p>\n X-Frame-Options<\/strong> decides whether the page may be embedded in a frame on someone else’s site, which is what stops a visitor from clicking on something invisible.<\/p>\n Referrer-Policy<\/strong> decides how much of the current address is passed on when a visitor follows a link away from the page.<\/p>\n A fifth, Permissions-Policy<\/strong>, switches off browser features the page does not need – camera, microphone, location. It is the least common of the five and the least likely to break anything.<\/p>\n Content-Security-Policy is the strongest of the five and the one most often defeated by its own value.<\/p>\n The threat it exists for is an injected script: something a visitor typed, or an attacker planted, ends up in the page and runs as if it belonged there. CSP prevents this by naming the sources the browser may execute code from, and a script written directly into the page has no source to name.<\/p>\n Which is precisely what A policy containing Strict-Transport-Security has one number that decides everything: It says how long the browser should remember the instruction. Until it expires, a plain unencrypted request to that domain is never sent – the browser rewrites it before it leaves the machine. That is the whole protection, and it only holds for as long as the memory lasts.<\/p>\n A Two additions matter. That last step deserves a warning: entries are hard to remove and removal takes months to reach browsers. It suits a domain whose encryption is settled, not one still being sorted out.<\/p>\n Framing is regulated twice, by two headers of different ages, and the rule for which one wins surprises people.<\/p>\n X-Frame-Options is the older one, understood everywhere, and offers When both are present, This is the failure that hides best, because both headers are present, both are spelled correctly, and a check that counts names reports two protections where there is one.<\/p>\n Referrer-Policy is the quietest of the five and the one with the most everyday consequences.<\/p>\n When a visitor follows a link away from a page, the browser tells the destination where the visitor came from. How much it tells is what this header sets. The path is where the sensitivity sits. The last of the three values is the sensible default, and modern browsers apply it on their own when the header is missing. Which makes an explicitly set All of this is public. The headers arrive with every response, for any address, and reading them takes one request.<\/p>\n Four questions are worth asking. Does a CSP exist, and does its value give back what it took away. Is the HSTS lifetime long enough to survive between two visits. Do the two framing headers agree, and does the one that wins say what was intended. And does the referrer setting pass on more than the destination needs.<\/p>\n The HTTP security header checker<\/a> answers all four for any address. It fetches the page once, reads the headers as a browser reads them, follows the redirects on the way, and judges the values rather than counting the names.<\/p>\n The useful result is not a grade. It is the short list of headers that are present and doing nothing – because those are the ones that will not be looked at again.<\/p>\n With nonces or hashes. A nonce is a random value that appears in the CSP as ‘nonce-\u2026’ and as an attribute on every permitted script; the browser then only runs inline scripts that carry this value. A hash (‘sha256-\u2026’) permits a script with exactly that content. An injected script neither knows the value nor matches the hash, and that is precisely what restores the protection ‘unsafe-inline’ took away.<\/p>\n As soon as a nonce or a hash appears in the policy, current browsers ignore an ‘unsafe-inline’ next to it. It can therefore stay as a fallback for very old browsers without weakening the protection in the others.<\/p>\n Two constraints follow. A nonce has to be generated afresh for every response; a page cache that serves the same HTML with the same nonce to everyone makes it known and therefore worthless, which is why hashes work better with caches. And event attributes such as onclick are not covered by nonces at all, and by hashes only with the additional keyword ‘unsafe-hashes’; moving them into scripts is the cleaner route. Until everything is in place, the Content-Security-Policy-Report-Only header shows what a policy would block without blocking it.<\/p>\n No. Browsers only honour Strict-Transport-Security in responses over HTTPS and ignore the header in an unencrypted response, because anyone along the way could have inserted or removed it there. The response on http:\/\/ should therefore only redirect to HTTPS, and the header belongs in the response that redirect leads to.<\/p>\n Both apply. The browser does not merge them into one common policy but checks each on its own, and a resource is only loaded if every policy permits it. A second, looser CSP therefore cannot weaken a strict one; a forgotten strict policy, in the web server configuration for instance, on the other hand blocks things the application expressly permits in its own policy.<\/p>\n Strict-Transport-Security behaves differently: if the header arrives twice, the browser processes only the first one, as RFC 6797 requires. When headers are set in several places, such as the web server, a plugin and a CDN, the response actually delivered is what needs checking, not the individual configurations.<\/p>\n No. A CSP in a meta element does not support frame-ancestors, nor report-uri or sandbox, and X-Frame-Options likewise only works as a real header. Protection against embedding therefore always needs a setting on the server or in the CDN.<\/p>\n<\/div>\n Security headers are checked by their names far too often. The name says a rule exists; only the value says whether it does anything – and some values cancel the very rule they belong to.<\/p>\n","protected":false},"author":1,"featured_media":16112,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[137],"tags":[91099,91219,91115],"class_list":["post-13477","post","type-post","status-publish","format-standard","hentry","category-tutorials-en-it-networks","tag-server-administration","tag-tutorial","tag-web-security"],"yoast_head":"\nThe rule that unsafe-inline cancels<\/h2>\n
'unsafe-inline'<\/code> permits again. The word is in the value for a reason – it says what it does – and it is there because a page full of small inline scripts stops working without it. Adding it is the fastest way to make a broken page work again, and it gives back the exact permission the policy was written to withhold.<\/p>\n'unsafe-inline'<\/code> still blocks a few things: code loaded from foreign addresses, for instance. Against the attack CSP is mainly for, it does close to nothing.<\/p>\n'unsafe-eval'<\/code> is the same story for a narrower case, and a default-src<\/code> of *<\/code> is the same story without any pretence.<\/p>\nHow long an HSTS lifetime has to be<\/h2>\n
max-age<\/code>, in seconds.<\/p>\nmax-age<\/code> of 300 remembers for five minutes. Formally correct, present in every check that counts names, and useless for a visitor returning the next day. The usual recommendation is a year, written as 31536000<\/code>.<\/p>\nincludeSubDomains<\/code> extends the rule to every subdomain, which closes the gap where a forgotten test system on the same domain gets reached unencrypted. And preload<\/code> asks for the domain to be built into browsers directly, so the protection covers the very first visit too – the one moment where HSTS otherwise cannot help, because nothing has been remembered yet.<\/p>\n![\"Four](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/illustrationen\/illu-security-header.webp\")
\n<\/figure>\nWhen two headers govern the same thing<\/h2>\n
DENY<\/code> or SAMEORIGIN<\/code>. CSP has frame-ancestors<\/code>, which does the same job with a list of addresses instead of two fixed choices.<\/p>\nframe-ancestors<\/code> wins and X-Frame-Options is ignored entirely. Not merged, not combined – ignored. A page with X-Frame-Options: DENY<\/code> and a CSP containing frame-ancestors *<\/code> can be framed by anyone, and the stricter of the two headers has no say.<\/p>\nWhat travels along with every click<\/h2>\n
unsafe-url<\/code> passes the full address including the path; no-referrer<\/code> passes nothing; strict-origin-when-cross-origin<\/code> passes the full address within the same site and only the domain to foreign ones.<\/p>\n\/en\/account\/orders\/48120<\/code> reveals a customer number, a password reset link reveals a token, and a search page reveals what was searched for. All of that goes to whichever site is linked to, in an ordinary header, without anything going wrong.<\/p>\nunsafe-url<\/code> worse than no header at all: it replaces a good default with a bad decision.<\/p>\nWhat a single fetch shows<\/h2>\n
Questions and answers<\/h2>\n
How can ‘unsafe-inline’ be dropped without moving every inline script out of the page?<\/h3>\n
Does an HSTS header sent over an unencrypted connection have any effect?<\/h3>\n
What happens when both the web server and the application send a CSP?<\/h3>\n
Can frame-ancestors also be set in a meta element?<\/h3>\n
Sources<\/h2>\n
\n